3014 Pre

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 • Child SA initiator ID
request (except ”initiator” changed • Child SA initiator certificate
to ”receiver”) IKE_AUTH response (encrypted) • Child SA receiver ID
• Child SA initiator authentication
• Child SA initiator traffic selector
• Child SA receiver traffic selector
For internal use

1 © Nokia Siemens Networks 2012
IPSec in E-UTRAN transport Table of Contents Main Menu
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

2 © Nokia Siemens Networks 2012 LTE Sys.PM – R.Kausl 2010
LTE: 3GPP Recommendations (Transport Security) Table of Contents Main Menu
• 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
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

4 © Nokia Siemens Networks 2012 MBB CS Network Engineering / Author / Date
IPSec parameters (1/4) Table of Contents Main Menu
• FTLB implements an IPSec security gateway to enable site-to-site VPN.

• All inbound IP packets entering FTLB from an IP interface in uplink and downlink is subjected to the packet filter if
IPSECC/ipSecEnabled=true.
• Packet filter for a security policy is defined using the IP parameter: protocol ID, src/dst IP subnet, src/dst port:
– IPSECC/remoteIpAddress
– IPSECC/remoteNetmask
– IPSECC/remoteIpPort = -1...65535, default = -1 (all ports)
– IPSECC/localIpAddress
– IPSECC/localNetmask
– IPSECC/localIpPort = -1...65535, default = -1 (all ports)
– IPSECC/protocol = -1...254, default = -1 (all protocols)
• There can be several security policies defined, each has its own packet filter.
– IPSECC/policyNumber
• If an uplink packet (coming from FSMx) matches a filter criterion, the corresponding security policy is applied to the packet:
– IPSECC/ipSecStatus = PROTECT (0), DISCARD (1), BYPASS (2), default = 2
For internal use

• Security parameters for IKE SA of the policy:

– IPSECC/ikeProtocol = IKE_V1 (0), IKE_V2 (1), default= 1
– IPSECC/ikeEncryptionMethod = ENC_AES_128_CBC (1), ENC_3DES_192_CBC (2),
ENC_AES_128_CBC_OR_3DES_192_CBC (3), default = 3
– (Other IKE parameters are hard-coded in eNB)
• Security parameters for child SA policy (ESP tunnel mode):

– IPSECC/saMaxLifeTime = 300...86400 seconds, default = 86400sec
– IPSECC/encryptionMethod = ENC_NULL (0), ENC_AES_128_CBC (1), ENC_3DES_192_CBC (2),
ENC_AES_128_CBC_OR_3DES_192_CBC (3), default = 3
– IPSECC/dpddelay = 10...360 seconds, default = 10 sec
– IPSECC/dpdtimeout = 60...3600 seconds, default = 120 sec
– IPSECC/antiReplayEnabled =true/false, default = true
– IPSECC/antiReplayWindowSize = SIZE_64 (0), SIZE_128 (1), SIZE_256 (2), default = 2
• IPSec tunnel (IKE SA tunnel) parameters:

– IPSECC/localTunnelEndpoint = IP@
– IPSECC/remoteTunnelEndpoint = IP@
For internal use

Parameter XML Name DB object Value range Default Description
ipSecEnabled IPSECC false (0), true (1) false (0) This parameter enables IPSec (value true) or disables (value false) usage of IPSec at the eNB.
This is a parameter structure that defines the list of security policies of the FTM. Each entry in the list consists of several
securityPolicies IPSECC parameter structure -
parameters, the most important ones are described below.
This parameter holds the local IP address of the data traffic packet for this policy as seen by the FTM. IPSec tunnel
selection based on the following combinations of local IP addresses and local port numbers and protocol are possible: i)
single IP address (equivalent to netmask /32 in IPv4), no particular protocol/port; ii) single IP address, selected protocol/port
; iii) IP subnet, no particular protocol/port; iv) IP subnet, selected protocol/port. For example, if the eNB U-plane virtual
localIpAddress IPSECC IPv4 address -
address is 10.10.10.1 and C-plane virtual address is 10.10.10.2, then one could map all U/C traffic to this IPSec tunnel by
setting localIpAddress = 10.10.10.0 and localNetmask = 255.255.255.252. Alternatively, instead of source subnet, the
traffic-to-IPSec-tunnel mapping can be based on destination subnet (or both). NOTE: mapping based on destination subnet
is the preferred planning approach, since it typically results in simpler database creation and management.
This is the port number of the local IP address. If value 0 is configured, the IPSec policy is valid in the same way to and
localIpPort IPSECC -1...65535, step 1 -1
from all ports of the local IP address. Value 0 corresponds to all ports.
This parameter specifies the netmask to the parameter localIpAddress. The type of localNetmask (IPv4 or IPv6) must match
localNetmask IPSECC IPv4 address -
the type of parameter localIpAddress.
This parameter holds the remote IP address of the data traffic packet for this policy. IPSec tunnel selection based on the
following combinations of remote IP addresses and remote port numbers and protocol are possible: i) single IP address
remoteIpAddress IPSECC IPv4 address -
(equivalent to netmask /32 in IPv4), no particular protocol/port; ii) single IP address, selected protocol/port ; iii) IP subnet, no
particular protocol/port; iv) IP subnet, selected protocol/port.
This is the port number of the remote IP address. If value 0 is configured, the IPSec policy is valid in the same way to and
remoteIpPort IPSECC -1...65535, step 1 -1
from all ports of the remote IP address.
This parameter specifies the netmask to the parameter remoteIpAddress. The type of remoteNetmask (IPv4 or IPv6) must
remoteNetmask IPSECC IPv4 address -
match the type of parameter remoteIpAddress.
This parameter holds the protocol information of the IP packet according to RFC791 (IPv4) or RFC1883 (IPv6). If the
protocol IPSECC -1...254, step 1, -1
parameter has value -1, the policy is valid for all protocols.
This parameter defines the local endpoint of the IPSec tunnel. It should equal either the physical Ethernet interface address
localTunnelEndpoint IPSECC IPv4 address -
of the VLAN interface address.
remoteTunnelEndpoint IPSECC IPv4 address - This parameter holds the remote IPSec tunnel endpoint IP address, i.e., the security gateway address.
antiReplayEnabled IPSECC false (0), true (1) If this flag is true,anti replay checking for the IPSec connections of this policy is enabled, else it is switched off.
For internal use SIZE_64 (0),SIZE_128 This is the size of the anti replay window to be used on the security policy.
antiReplayWindowSize IPSECC
7 © Nokia Siemens Networks 2012 (1), SIZE_256 (2) The parameter is only relevant if the parameter antiReplayEnabled has the value True.
Parameter XML Name DB object Value range Default Description
This flag rules the basic treatment of a traffic data packet that applies to the selection criteria of this policy. The
values have the following meaning: "DISCARD": the packet is discarded without any further action or notification, i.e.
PROTECT (0), DISCARD (1),
ipSecStatus IPSECC BYPASS (2) it is prevented from passing to its designated destination. "BYPASS": the packet is delivered to its destination without
BYPASS (2)
any other processing, in particular without any further IPSec-related processing. "PROTECT": the packet will be made
subject to the settings of its security policy.
ENCRYPTION_NULL (0),
AES_128_CBC (1), 3DES_192_CBC ENC_AES_128_CB
encryptionMethod IPSECC (2), C_OR_3DES_192_ This parameter defines the encryption algorithm to be applied to the traffic data packet for which the policy matches.
AES_128_CBC_OR_3DES_192_CB CBC (3)
C (3)
ikeProtocol IPSECC IKE_V1 (0), IKE_V2(1) IKE_V2 (1) This parameter holds the IKE protocol version of this association used for this policy.
AES_128_CBC (1), 3DES_192_CBC

ENC_AES_128_CB
(2), This parameter holds the encryption algorithm at the IKE layer to be applied to the IKE protocol packet. Note that
ikeEncryptionMethod IPSECC C_OR_3DES_192_
AES_128_CBC_OR_3DES_192_CB encryption is always used in IKE protocol.
CBC (3)
C (3)
This parameter holds the maximum duration in seconds of the life time of the security association. After the timer has
saMaxLifeTime IPSECC 300...86400 seconds, step 1 86400 expired for the security association, a new security association is negotiated by IKE. The default value corresponds to
24 hours.
This is the IPSec tunnel endpoint for IKE protocol. It should equal to the value of the IPSECC/remoteTunnelEndpoint
remoteTunnelEndpoint IPSECC IPv4 address -
parameter.
This parameter specifies the delay between the sending of two consecutive DPD INFORMATIONAL messages by the
BTS. The INFORMATIONAL message indicates the BTS is still alive. For IKEv2, the BTS raises the Dead Peer
dpddelay IPSECC 10…360 seconds 10 Detected (DPD) alarm if the remote peer has not sent any INFORMATIONAL message to the BTS after the BTS has
sent a fixed number of INFORMATIONAL messages. For IKEv1 the BTS raises the DPD alarm, if the remote peer
has not sent back any INFORMATIONAL messages after the time defined in the parameter dpdtimeout has expired.
For IKEv1, the BTS raises the Dead Peer Detected (DPD) alarm if the remote peer has not sent back any
dpdtimeout IPSECC 60...3600 seconds 120
INFORMATIONAL messages after the time defined in the parameter dpdtimeout has expired.
For internal use This is the order number of the security policy. Only the lowest number of several equally matching policies is
policyNumber IPSECC 0...65535, step 1 -
8 © Nokia Siemens Networks 2012 executed on a specific traffic data packet.
LTE689 – LTE IPSec Support Main Menu
Table of Contents
Introduction
Technical Details
3 Parameters
Deployment Aspects
For internal use

Public Key Infrastructure – PKI Components Table of Contents Main Menu
Certificate Server • Registration Authority RA

• Responsible for the registration and initial
authentication of subjects (subscribers in case of
Certification Authority humans) asking for a public certificate
• Certification Authority CA
• Responsible for establishing the identities and creating
and signing the digital certificates
Certificate • Certificate repository
Certificate
Registration
Authority Repository • Public available repository, place to publish public
certificates, usually LDAP directories
• Certificate Server
• Machine or server responsible for certificate issuing
• Often used when CA is meant
End entity (eNB) • RA, CA and Repository may share the same server or
different machines
For internal use

eNB initial registration to operators’ PKI with vendor device certificate Table of Contents Main Menu
A trust relation ship exists between Nokia Siemens Networks and the operator:
• Nokia Siemens Networks provides for each Flexi Multimode BTS a unique vendor device
certificate signed by the Nokia Siemens Networks CA
• As part of the delivery the operator gets a list of all shipped modules (serial numbers) and the
Nokia Siemens Networks public root certificate
When the eNB auto connects to the operator’s network it utilizes the CMP in-band initialization
procedure to ask for an operator’s eNB certificate:
• The Flexi Multimode base station / eNB sends a public key for signing as well as it’s vendor
device certificate and serial number
• The operator CA verifies the vendor device certificate with the help of the Nokia Siemens
Networks root certificate
• If Nokias Siemens Networks Identity Management Solution (IDM) is in place the serial number is
automatically checked against the order list
• If both verifications passed the CA signs the key and issues the operator device certificate to
the Flexi Multimode Bases station
For internal use

eNB initial registration to operators’ Table of Contents Main Menu
PKI with vendor device certificate (CMPv2: Annex E7)
Trigger: A new installed eNB wishes to initialize the operator’s PKI:
Identity Management Operator Certification

System Authority CA Root
Cert
Generate key pair

NSN device
Sign initialization request with vendor device private key
NSN Root
Cert CMP: Initialization Request ( vendor device cert, public key ,serial number) Cert
S/ N
Verify vendor certificate & serial number Ord
Sign public key and issue certificate
er
Encrypts the signed cert with vendor device public key
list
OP device
Cert
CMP: Initialization Response (operator device cert, Operator CA cert, trust anchors)
decrypts CA signed cert with vendors device private key

CA Root validate CA signed cert with CA public key
Cert
CMP: Certificate Confirmation
NSN device
Cert
CMP: PKI Confirmation
OP device
Cert NSN device cert swapped by operator device cert
For internal use

Certification parameters (CERTH) Table of Contents Main Menu
• Needed if CMP and CRL server are used for eNB authentication and certificate revocation,
• NSN PKI solution is the InstaCertifier,
• Parameters to be planned:
– CERTH/cmpServerIpAddress
– CERTH/cmpServerPort
– CERTH/caSubjectName = 0...128 characters
– CERTH/btsCertificateUpdateTime
– CERTH/caCertificateUpdateTime
– CERTH/crlUpdatePeriod
• The settings must match with the server settings and hence planned together with the
security administrator/planner.
For internal use

13 © Nokia Siemens Networks 2012 Presentation / Author / Date
Certificates from eNB and SEG Table of Contents Main Menu
• The following must be in place in both eNB and SEG if using X.509
signatures for authentication:
– CA root certificate,
– private key,
– eNB certificate.
• Normally the above are obtained from CMP server prior to IPSec tunnel
setup. They can be also loaded manually to eNB using the site manager.
For internal use

14 © Nokia Siemens Networks 2012 Presentation / Author / Date
IKEv2 dead peer detection, RFC 3706 Table of Contents Main Menu
• Sometimes the other IPSec peer can disappear without properly deleting the SA, for example because the node is
being rebooted or physical connection was cut.
• To prevent hanging SAs, Dead Peer Detection has been specified

– A peer will send an ISAKMP INFORMATIONAL message that contains ARE-U-THERE message
– Whenever an IPSec peer receives an ARE-U-THERE it responds with ARE-U-THERE-ACK
– These messages must be encrypted
– Both IPSec peers must support DPD, this is indicated by DPD Vendor Id messages before DPD exchange
• The actual implemetation details that are left open in the RFC:
– when to send ARE-U-THERE? Example trigger from Linux StrongSwan implementation: when there is no traffic in
the SA pipe for dpddelay seconds, where dpddelay is user-definable parameter
– when and how to react if there is no response? Example from Linux StrongSwan implementation: retransmit ARE-
U-THERE in increasing time intervals up to five times. If no response, release the SA.
• Note: there is, in principle, no need for planning coordination the DPD timers between peers (though, it may happen
that one end will always trigger ARE-U-THERE first).
For internal use

LTE564 – IPSec on FTIB
Main Menu
For internal use

Unique document identifier (ID) / Version number / Life cycle status
16 © Nokia Siemens Networks 2012 MBB CS Network Engineering. / Author / Date
LTE564 – IPSec on FTIB Main Menu
Table of Contents
Introduction Configuration Management

1 Motivation and Feature Overview 5 Parameters
Interdependencies Dimensioning Aspects

2 Interdependencies with Other Features and Functions
6 Dimensioning Impacts and Examples
Technical Details Performance Aspects

7 Counters and KPIs
Deployment Aspects References

8 References to Other Materials
NEI Contact: Radoslaw Ruchala, Roman Arcea
For internal use

Introduction Table of Contents Main Menu
 This feature enables secure eNB control and data communication between the Flexi Multiradio
BTS and other eNBs and Core Nodes by using IPSec to secure transport and application
protocols.
 With IPSec also the separation between different types of traffic, like C-Plane and U-Plane traffic
from M-Plane traffic, by dedicated transport tunnels is supported
 Benefits for the operator:
– Improved RAN network security
– Possibility of traffic separation within the backhaul
– CAPEX savings: no external HW equipment needed at the eNB side
For internal use

IPSec with FTLB module (LTE689)
3 x GE 1)
4 x E1/T1/JT1 2)4)
High-capacity IPSec 3)4)
ToP (IEEE1588-2008), Sync Ethernet 4)
Ethernet switching 5)
Non-blocking throughput performance with IPSec
Flexi Multiradio BTS
System Module 1) 2 x GE electrical + 1 x GE optical via SFP module
2) E1/T1/JT1 interface for synchronization
with 3) IPSec HW capability: 2 Gbit/s DL+UL
4) SW support with RL10
Flexi Transport sub-module FTLB 5) SW support with RL20
For internal use

IPSec with FTLB module (LTE689)
Non-blocking throughput performance with IPSec
FTLB – Schematic Interfaces and Subnet Overview
BTS Transport
− IPSec processing done by a
S internal
Public
LMP SSE Subnet for
SSE
Subnet
PPP
IPSec processing
dedicated HW (Cavium Router)
User defined
Router (CV)
− Does not affect traffic processing
LLP
FSP1 eth0
IWF
done in the main board (WP
I eth1 eth2 eth3
U-Plane X
P H
PPP TRS
Ip
INT
Ip
TRS Router)
PDH 1- 4 C A
FSP2 ppp
J
U-Plane Y P Q
P
TRS D
G BTS IWF
FSP3 eth0 eth1 EIF
K N INT
U-Plane Z
P
Sw itch
ToP E
R O
private net public net

Router
FCM F
L (WP) Private IP address
C/M-Plan e
M ToP
Q Public IP address
S-Plane
FTLB QoS(DSCP) set here
Soc Classification level

19 © Nokia Siemens Networks
For internal use

2 x GE 1)
4 x E1/T1/JT1 2)
IPSec 3)4)
ToP (IEEE1588-2008), Sync Ethernet
Ethernet switching 4)
Non-blocking throughput performance without IPSec

Flexi Multiradio BTS
System Module
1) 2 x GE electrical or 1 x GE electrical + 1 x GE optical via SFP module
with 2) E1/T1/JT1 interface for synchronization
3) IPSec HW capability: 160 Mbit/s DL+UL
Flexi Transport sub-module FTIB 4) SW support with RL20
For internal use

Non-blocking throughput performance without IPSec
FTIB – Schematic Interfaces and Subnets Overview
− IPSec processing done jointly

S
BTS
int ernal
Public
LMP SSE Subnet for
Transport
Subnet with the main processing stream
PPP
SSE
User defined
(in WP Router)
LLP − Does affect mainstream traffic
FSP1
U-Plane X
I
IPSec processing processing
P H
FSP2
J ppp
PPP TRS
PDH 1- 4 − FTIB throughput with IPSec
U-Plane Y P Q
P
IWF
IP
TRS
A
EI F limited to 160 Mbit/s DL+UL
G BTS
FSP3 et h0 et h1
K N INT
U-Plane Z
P
Sw itch
ToP E
R O
private net public net

Router
FCM F
L (WP) Private IP address
C/ M-Plane
M ToP
Q Public IP address
S-Plane
FTIB QoS (DSCP) set here
For internal use

Soc Classification level
22 18
© ©Nokia Siemens Networks
Nokia Siemens Networks
2012
Table of Contents



7 Counters and KPIs

For internal use

Interdependencies Table of Contents Main Menu
 Release information:
System release RL20
eNode B LBTS 2.0
NetAct -
MME -
SAE-GW -
 HW/SW requirements:
− LTE564 is supported by Flexi MRD BTS, with:
 Flexi BTS system modules (FSM): FSM R2
 Flexi transport sub-modules (FTM): FTIB
 Feature dependencies:
− LTE564 depends on the following features:
 LTE707 Flexi Transport sub-module FTIB (RL10)
− LTE564 is analogous to feature LTE689 LTE IPSec Support for control, user and
management plane, supported on FTLB, except some differences in the internal IPSec
processing on FTIB and FTLB boards (see next slides)
For internal use

Table of Contents



7 Counters and KPIs

For internal use

Technical Details Table of Contents Main Menu
 IPSec is a L3 security architecture defined by IETF; it comprises a suite of protocols for data
encryption, integrity protection and communication peer authentication according to RFC4301.
 Fundamental components of IPSec:
 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
 IPSec can be also used to implement VPNs on L3, for traffic separation
 U-Plane, C-Plane, M-Plane and S-Plane traffic can be separated with dedicated IPSec VPN tunnels from
each other and from any other operator’s traffic if any part of the transport network is shared.
 Separation ensures that any attacks from affected/unsecured network parts will have no impact to the
separated data paths.
For internal use

LTE564 - 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
Services:
anti-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)
Key Management: ISAKMP
Diffie-Hellman key exchange: Group 2 (1024-bit MODP)
For internal use

LTE564 - Supported IPSec functionality in LTE RL10 & RL20 (2/2)
 LTE RL10 and RL20 implement a subset of the full IPSec protocol suite
ISAKMP 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:
fall-back to IKEv1
IPSet set-up initiation By eNB during Network Integration (start-up)
Dead peer detection For IKE v1 and IKEv2 (inherent)
For internal use

Table of Contents



7 Counters and KPIs

For internal use

Deployment Aspects Table of Contents Main Menu
LTE564 - Basic IPSec network scenario in LTE e-UTRAN
Flexi BTS Transport Interface IP@ (VLAN or Eth)

Standalone
Security
Gateway MME
Integrated SEG
Security Association pair SA#1
Application IP@
Security Association pair SA#2 SAE-GW
Security Association pair SA#3
Network
Security Association pair SA#n Management
2 alternatives possible:
 Security on Transport level: „Outer” secured communication channel in a VPN mode (FlexiBTS ↔ SEG)
 Security on Application level: „Inner”, e2e secured communication channel (typically separate for UP, CP, MP and SP (if supported))
 Both in a form of Security Association established with ISAKMP protocol
For internal use

LTE564 - X2 Star“ Use Case: „IPSec VPN“
U X2-u/c
Single
tunnel per MME
C
Ethernet
eNB
Tunnel IP
M
VLAN SAE-
optional SEG
S GW
eN
B O&M
IPSec VPN
IPSec tunnel: “outer” IP layer
IPSec tunnel: “inner” IP layer
Application address (inner Interface address (outer IP

IP address) address)
For internal use

Table of Contents



7 Counters and KPIs

For internal use

Configuration Management Table of Contents Main Menu
LTE564 - Parameters
Parameter Description
full name: ipSecEnabled

This parameter switches IPSec globally on (value true) or off (value false) at the eNB
object: IPSECC
range: 0 (false),
1 (true),
default: false
unit: -
This is a parameter structure that defines the list of security policies of the FTM. Each entry in the list consists of several
full name: securityPolicies parameters.
object: IPSECC Parameters included in this strucuture:
range: parameter structure antiReplayEnabled, antiReplayWindowSize, authentication, dpddelay, dpdtimeout, encryptionMethod, ikeEncryptionMethod,
default: - ikeProtocol, ipSecStatus, localIpAddress, localIpPort, localNetmask, localTunnelEndpoint, policyNumber, protocol,
unit: - remoteIpAddress, remoteIpPort, remoteNetmask, remoteTunnelEndpoint, saMaxLifeTime
This parameter holds the local IP address of the data traffic packet for this policy as seen by the FTM. To be entered in dotted
decimal format.
full name: localIpAddress
object: IPSECC The following combinations of local and remote IP addresses, local and remote port numbers and protocol are feasible:
range: IPv4 address - a single IP address (equivalent to netmask /32 in IPv4), no particular protocol/port
default: - - a single IP address, selected protocol/port
unit: - - an IP subnet, no particular protocol/port
- an IP subnet, selected protocol/port.
For internal use

LTE564 - Parameters
This is the port number of the local IP address. If value -1 is configured, the IPSec policy is valid in the same way to and from
all ports of the local IP address.
full name: localIpPort The following combinations of local and remote IP addresses, local and remote port numbers and protocol are feasible:
object: IPSECC - single IP address (equivalent to netmask /32 in IPv4), no particular protocol/port
Range and step: -1..65535, step 1
- single IP address, selected protocol/port
default: -1 (all ports are allowed)
unit: - - IP subnet, no particular protocol/port
- IP subnet, selected protocol/port.
full name: localNetmask This parameter specifies the netmask to the parameter localIpAddress. The type of localNetmask (IPv4 or IPv6) must match
object: IPSECC the type of parameter localIpAddress.
range: IPv4 address
default: -
unit: -
full name: localTunnelEndpoint

object: IPSECC
range: IPv4 address
This parameter defines the local endpoint of the IPSec tunnel. It should equal either the physical Ethernet interface address or
the VLAN interface address.
default: -
unit: -
For internal use

LTE564 - Parameters
This parameter holds the remote IP address of the data traffic packet for this policy as seen by the FTM. To be entered in
dotted decimal format.
full name: remoteIpAddress The following combinations of local and remote IP addresses, local and remote port numbers and protocol are feasible:
object: IPSECC - a single IP address (equivalent to netmask /32 in IPv4), no particular protocol/port
range: IPv4 address
- a single IP address, selected protocol/port
default: -
unit: - - an IP subnet, no particular protocol/port
- an IP subnet, selected protocol/port.
This is the port number of the remote IP address. If value -1 is configured, the IPSec policy is valid in the same way to and from
all ports of the remote IP address.
full name: remoteIpPort The following combinations of local and remote IP addresses, local and remote port numbers and protocol are feasible:
object: IPSECC - single IP address (equivalent to netmask /32 in IPv4), no particular protocol/port
Range and step: -1..65535, step 1
- single IP address, selected protocol/port
default: -1 (all ports are allowed)
unit: - - IP subnet, no particular protocol/port
- IP subnet, selected protocol/port.
full name: remoteNetmask This parameter specifies the netmask to the parameter remoteIpAddress. The type of remoteNetmask (IPv4 or IPv6) must
object: IPSECC match the type of parameter remoteIpAddress.
range: IPv4 address
default: -
unit: -
For internal use

LTE564 - Parameters
This parameter defines the remote endpoint of the IPSec tunnel. It should equal either the physical Ethernet interface address
full name: remoteTunnelEndpoint or the VLAN interface address.
object: IPSECC
range: IPv4 address
default: -
unit: -
full name: ipSecStatus This flag rules the basic treatment of a traffic data packet that applies to the selection criteria of this policy. The values have the
object: IPSECC following meaning: "DISCARD": the packet is discarded without any further action or notification, i.e. it is prevented from
range: 0 (PROTECT) passing to its designated destination. "BYPASS": the packet is delivered to its destination without any other processing, in
1 (DISCARD)
particular without any further IPSec-related processing. "PROTECT": the packet will be made subject to the settings of its
security policy.
2 (BYPASS)
default: BYPASS
unit: -
This parameter holds the ESP encryption algorithm to be applied to the traffic data packet for which the policy matches.
full name: encryptionMethod
The default value for ESP encryption algorithm offers 2 values (priority list) where
object: IPSECC
range: 0 (ENC_NULL),
- AES-128 CBC is tried first (1. priority) and
1 (ENC_AES_128_CBC), - 3DES-192 CBC is tried next (2.priority).
2 (ENC_3DES_192_CBC),
3 (ENC_AES_128_CBC_OR_3DES_192_CBC) )
default: (3)
unit: -
For internal use

LTE564 - Parameters
This parameter determines if this policy is using a pre-shared key or a certificate in IKE. Certificate is obtained from CMP
full name: authentication
server during eNB startup or downloaded manually to eNB using the site manager.
object: IPSECC
range: 1 (certificate), 2 (psk)
default: certificate
unit: -
This parameter holds the IKE protocol version of this association used for this policy.
full name: ikeProtocol
object: IPSECC
range: IKE_V1 (0), IKE_V2 (1)
default: IKE_V2
unit: -
This parameter holds the encryption algorithm at the IKE layer to be applied to the IKE protocol packet. Note that encryption is
full name: ikeEncryptionMethod always used in IKE protocol.
object: IPSECC
range: 0 (ENC_NULL),
1 (ENC_AES_128_CBC),
2 (ENC_3DES_192_CBC),
3 (ENC_AES_128_CBC_OR_3DES_192_CBC) )
default: (3)
unit: -
For internal use

LTE564 - Parameters
This parameter holds the maximum duration in seconds of the life time of the security association. After the timer has expired
full name: saMaxLifeTime
for the security association, a new security association is negotiated by IKE. The default value corresponds to 24 hours.
object: IPSECC
range: 300...86400 sec, step 1 sec
default: 86400
unit: seconds
This parameter specifies the delay between the sending of two consecutive DPD INFORMATIONAL messages by the BTS.
The INFORMATIONAL message indicates the BTS is still alive.
full name: dpddelay
object: IPSECC For IKEv2, the BTS raises the Dead Peer Detected (DPD) alarm if the remote peer has not sent any INFORMATIONAL
range: 10…360 seconds
message to the BTS after the BTS has sent a fixed number of INFORMATIONAL messages. For IKEv1 the BTS raises the
DPD alarm, if the remote peer has not sent back any INFORMATIONAL messages after the time defined in the parameter
default: 10 sec
dpdtimeout has expired.
unit: seconds
full name: dpdtimeout For IKEv1, the BTS raises the Dead Peer Detected (DPD) alarm if the remote peer has not sent back any INFORMATIONAL
object: IPSECC messages after the time defined in the parameter dpdtimeout has expired.
range: 60...3600 seconds
default: 120 sec
unit: seconds
For internal use

Table of Contents



7 Counters and KPIs

For internal use

Dimensioning Aspects Table of Contents Main Menu
 IPSec frame structure with ESP and tunnel mode:

 For the traffic in tunnel mode, the original IP frame is encapsulated in the payload field of the
ESP frame. The IP frame after encapsulation has the following format:
UDP ESP
IP header ESP header Original IP header Payload ESP trailer
header Authentication
Encrypted
Authenticated
Transmission order
0 31
 IPSec in this configuration introduces an IP header (20 bytes)
additional overhead of 71 bytes to the original IP Security Parameters Index (SPI) (4 bytes)
datagram: Extended Sequence Number (4 bytes)
Transmission order
Authenticated
ESP header: 24 bytes Initialization Vector (AES-CBC: 16 bytes)
Explicit padding: 15 bytes
Payload
(n*16bytes)
ESP Authentication data: 12 bytes
Encrypted
Outer IP header: 20 bytes Padding
Total: 71 bytes Pad Length Next Header
(1 byte) (1 byte)
 This results in an additional IP bandwidth
Authentication Data (SHA-1-96: 12 bytes)
requirement of ~ 15% for a typical user profile
For internal use

Table of Contents



7 Counters and KPIs

For internal use

Performance Aspects Table of Contents Main Menu
LTE564 – KPIs and PM Counters
LTE IP Sec measurement (M51125) contains counters for counting protected, discarded and bypassed
bytes and frames for IPSec
Protected_ESPFramesTX (ID: M51125C0)
For internal use

Protected_ESPFramesRx (ID: M51125C1)
For internal use

Discarded_ESPFramesTx (ID: M51125C2)
For internal use

Discarded_ESPFramesRx (ID: M51125C3)
For internal use

Bypassed_ESPFramesTx (ID: M51125C4)
For internal use

Bypassed_ESPFramesRx (ID: M51125C5)
For internal use

Table of Contents



7 Counters and KPIs

For internal use

References Table of Contents Main Menu
 LTE Security SFS

doors/LTE System/LTE SFS Modules/Security/Security SFS
 LTE IPSec training by NPO Capability Development:

https://sharenet-ims.inside.nokiasiemensnetworks.com/Overview/D424300323
 LTE IPSec presentation by LTE Transport PLM:

contact Mr. Torsten Musiol (torsten.musiol@nsn.com)
 Training Security in Radio Access Networks by NWS Engineering & Platforms /

Transport Architecture:
contact Mr. Helmut Heeke (helmut.heeke@nsn.com) or Mr. José Tapia Perez
(jose.tapia-perez@nsn.com)
For internal use

LTE150 - LTE OAM Transport Layer Security
(TLS) Support
Main Menu
For internal use

LTE150 – LTE OAM TLS Support Main Menu
Table of Contents
Introduction
Technical Details
3 Parameters
NEI Contact: Szymon Listwan, Roman Arcea
For internal use

LTE150 - LTE OAM Transport Layer Security (TLS) Support
Feature summary
• Enables secure communication of O&M control and bulk data between the Flexi Multiradio BTS LTE
at one end, and BTS Site Manager and NetAct or other management systems at the other end.
• The feature includes a PKI infrastructure by employing secure protocols such as Transport Layer
Security (TLS).
• The feature also brings CAPEX savings, as there is no need to invest in any external HW.
• Applied together with LDAP, TLS takes care of confidential user credential exchange
For internal use

Comparison to WCDMA
Two major differences comparing to WCDMA:
– Air interface security of U-plane and C-plane (RRC) traffic is terminated at the eNodeB.
Traffic in the LTE mobile backhaul network is not secured by Radio Network Layer protocols
– LTE network architecture is flat  adjacent eNBs and core nodes (MME, S-GW) become directly
IP-reachable from eNB site.
If physical access to the site cannot be prohibited, a hacker could connect his device to the network
port and attack aforementioned network elements.
Transport security features are seen mandatory if not both the mobile backhaul network and the
eNodeB site can be regarded as secure.
For internal use

Security Threats in WCDMA
Threat level: Medium
U-plane & C-plane (RRC) secured
C-plane (NBAP) not

secured
RNC Internet
C-plane can be
RNC can be
maliciously
attacked
manipulated
For internal use
Security Threats in WCDMA
Threat level: Very High
U-plane & C-plane

U-plane & C-plane not secured
secured
Internet
User traffic can be C-plane can be Core nodes and

can be maliciously adjacent eNB’s can
eavesdropped manipulated be attacked!
For internal use

IPSec in E-UTRAN transport
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 (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
Table of Contents
Introduction
Technical Details
3 Parameters
For internal use

Transport Layer Security (successor of Secure Socket Layer Protocol, SSL)

provides encryption, integrity protection and authentication features.
Consists of two layers:

1. The TLS record protocol
– provides encryption and integrity protection of the message exchange.
2. The TLS handshake protocol
– provides mutual authentication of the communication peers by means of digital
certificates.
 the certificates’ CA signature and lifetime are validated
 This mutual authentication prevents man-in-the-middle and masquerade attacks.
• eNB and iOMS support TLS version 1.0 [RFC 2246].
For internal use

Security is assured by the Transport Layer Security Protocol and further protocols such as HTTP or
LDAP running on top of it:
– Unsecure protocols such as FTP are no longer used.
– TLS is a secure communication method for protecting the confidentiality and integrity of, for
example, Java, HTTP and LDAP based O&M traffic.
Digital certificates according to X.509v3 format are used to mutually authenticate the eNB, the BTS Site
Manager, and network servers such as NetAct.
O&M interfaces, messages and commands are encrypted and integrity protected by TLS. Data such as
user names and passwords is not transferred as plain text.
For internal use

LTE150 – Overview of TLS
Transport Layer Security is a protocol:
• that guarantees privacy and data integrity between Client and Server applications communicating over public
network
• communicated information can be protected from:
– eavesdropping
– tampering
– message forgery
• TLS is implemented on top of Transport Layer

 it is application protocol-independent.
 application protocols can layer on top of the TLS protocol transparently.
• Based on SSL3.0 (Secure Sockets Layer), TLS supercedes and is an extension to SSL. TLS and SSL are not
interoperable.
For internal use

LTE150 – Overview of TLS
TLS benefits to the upper layer protocols using appropriate cryptography

– strong authentication (using X.509 certificates)
– message privacy(using conventional encryption),
– integrity(using Message Authentication Codes)
• Interoperability
• Algorithm flexibility
• Ease of deployment
• Ease of use
For internal use

LTE150 – TLS Limitations
Limitations of TLS are as follows:
Increased processor load

– Cryptography, specially public key operations, is CPU-intensive, which results performance variance.
– The performance varies, depending on how often connections are established and how long they last.
– TLS uses the more resources during connection setup.
Administrative overhead
– A TLS/SSL environment is complex and requires maintenance.
– The system administrator must configure the system and manage certificates.
For internal use

LTE150 – TLS Secure Connection Establishment
To use TLS for client/server communication

• Handshake and cipher suite negotiation
• Authentication of parties(client and server)
• Key-related information exchange
• Application data exchange
• The steps that make up TLS are divided broadly into two steps that, together, provide connection security:
• TLS Handshake Protocol – (steps 1 -3)
• TLS Record Protocol – (step 4)
• Here TLS Handshake Protocol is only explained in detail and no explaination is given for the record protocol as it
is data exchange between client and server and it has got nothing to do with TLS connection establishment.
For internal use

LTE150 – TLS Secure Connection Establishment Diagram
For internal use

LTE150 – LDAP Secured with TLS (1/2)
The LDAP interface for user authentication and provision of permission information for a user is secured by
TLS:
‒ The NetAct centralized user authentication and authorization (CUAA) application and other services use the
LDAP interface to authenticate a user and to fetch permission information for a user.
‒ Insecure connections on the LDAP link between the BTS and the LDAP servers lead to a situation where a user's
username and password are transferred in plain text across the O&M network.
‒ No longer the case with the secure LDAP feature:

‒  LDAP interface is secured by means of TLS using AES-128 encryption and the related integrity
protection according to LDAPv3 as specified in RFC 4513.
For internal use

LTE150 – LDAP Secured with TLS (2/2)
LDAP Operation Modes (ldapConnectionType parameter)

Probe
‒ A secure O&M connection is established.
‒ In the event of an error in TLS communication, the eNB and iOMS is allowed to try a plain text (insecure)
connection to the LDAP server.
‒ Failed communication attempts are logged in both eNB and iOMS.
Forced
‒ A secure O&M connection is established.
‒ The eNB is not allowed to open plain text (insecure) connections.
‒ Failed connections attempts are logged in both eNB and iOMS.
Off
‒ The eNB and iOMS establishes a plain text (insecure) LDAP connection.
‒ LDAP needs to accept such insecure O&M connections.
Insecure and secure O&M connections are established on separate TCP ports. By opening or closing these
ports, secure and insecure connections can be activated and deactivated
For internal use

LTE150 – O&M TLS (1/5)
eNB TLS Operation Modes (omsTls parameter)

Probing (Secure/Unsecure)
– Both secure and unsecure O&M connections are allowed between iOMS and eNB.
– If the connection setup to both secure and insecure ports fails, the eNB starts the connection procedure from
the beginning, that is, it tries to establish secure connection first.
Forced
– Only secure O&M connections are established between iOMS and eNB.
Off
– Only unsecure O&M connections are established between iOMS and eNB.
The same ports are used for both secure and unsecure connections; for eNB these ports are
configurable using BTSSM.
Make sure to have the configuration matched between the operation mode settings in eNB and iOMS.
If the settings differ, the eNB might not be able to connect, but will continue trying to connect even though the
iOMS connection port is closed.
For internal use

LTE150 – O&M TLS (2/5)
BTS O&M protocol (OM) security mode in iOMS
OM Security Mode parameter in iOMS can be configured as:

Forced
– Only secure O&M protocol connection are established. The iOMS and the eNB use the
TLS_RSA_WITH_AES_128_CBC_SHA cipher suite. The insecure port (8002) is closed.
Probing (Secure/Unsecure)
– Both secure and unsecure O&M protocol connections are allowed. Both secure and insecure ports are open.
– When the parameter value is changed from Off to Probing, iOMS resets the port 8002 to trigger the eNB
change from insecure to secure connection.
Off
– Only unsecure O&M protocol connections are allowed. The secure port (8003) is closed.
For internal use

LTE150 – O&M TLS (3/5)
File Transfer (FT) security mode in iOMS

“FT Security Mode” parameter which can be configured as:
Forced
– Only secure file transfers are allowed.
– The secure port (443) is open. Insecure ports are closed (FTP 20, HTTP 80).
– This is the default value.
Probing
– Both secure and insecure file transfers are allowed between iOMS and eNB. Secure file transfer is tried first.
File transfers between iOMS and NetAct are in secure mode only.
– Both secure and insecure ports are open.
Off
– Only insecure file transfers are allowed.
– Both secure and insecure ports are open.
If the negotiated file transfer protocols allow both insecure and secure file transfers, and the file transfer
attempts from both secure and insecure ports fails, the client does not retry, but aborts the procedure.
For internal use

LTE150 – O&M TLS (4/5)
Parallel usage of TLS and other secure transport protocols
Depending on the transport network configuration and the number of network management locations and applications
to be addressed, TLS (one or more instances) alone or together with other secure transport protocols like IPSec
can be used and configured in parallel.
For instance, it is possible to run TLS within a common IPSec tunnel.
For internal use

LTE150 – O&M TLS (5/5)
Secure BTS Site Manager connection

The BTS Site Manager (BTSSM) by default tries to establish a secure connection (Site Manager connection) to an
eNB.
• If the eNB (acting as TLS server) certificate validation fails in BTSSM (acting as TLS client), the BTSSM asks user
permission to establish the secure connection even if the eNB certificate is "unknown" to BTSSM.
The "unknown" certificate can be:

– an eNB Operator certificate which cannot be validated by BTSSM (for example, Trusted CA not configured on
BTSSM),
– the Nokia Siemens Networks certificate (which cannot be validated by BTSSM),
– an eNB self-signed certificate (which cannot be validated by BTSSM).
If the user accepts, a secure connection is established
If the secure connection establishment fails, BTSSM attempts to establish an unsecure connection; in this case
BTSSM has to be locally connected to the eNB
For internal use

Table of Contents
Introduction
Technical Details
3 Parameters
For internal use

LTE150 - Parameters
Parameter XML Name DB object Value range Default value Description
Defines the usage of TLS between the eNB and the iOMS system.The usage of TLS
omsTls IPNO off (0), forced (1), probing (2) probing
requires that valid certificates are installed to the eNB.
This parameter holds the TLS access mode for the LDAP server(s) of the BTS. The possible
ldapConnectionType AMGR TLS (0), TLS_OR_PLAIN_TEXT (1) - values are: "secured" (allow only secured connections) and "both" (allow both unsecured
and secured connections).
For internal use

LTE482 - DNS Support for certificate examination
Main Menu
For internal use

Main Menu
Table of Contents
Introduction Benefits and Gains

1 Motivation and Feature Overview 5 Simulation, Lab and Field Findings

2 Functionality and Implementation, Message Flows 6 Counters and KPIs
Configuration Management References

3 Parameters 7 References to other sources
Deployment Aspects
For internal use

• A part of the X.509 certificate examination is the check if the certificate has been
revoked.
• The URL of the revocation repository server (CRL Distribution Point) is given by a Full
Qualified Domain Names (FQDN) within the certificate.
• Domain Name Service (DNS) is used to derive the corresponding IP address.
For internal use

Main Menu
Table of Contents



Deployment Aspects
For internal use

• Certificates of remote peers (received as part of IPSec or TLS establishment) and configured trust
anchors need to be checked if they are valid and have not been revoked
• To allow this examination each certificate contains the URL of the responsible revocation repository
server given by a Full Qualified Domain Name (FQDN).
• The DNS client in Network Element (NE) sends the FQDN of the CRL Distribution Point to a DNS
name server which returns the corresponding IP address assigned to the repository.
NetAct NE CRL Distribution

point
Trigger to retrieve new

CRL
Resolve CRL server
IP@
CRL retrieval procedure
For internal use

NetAct/OMS eNB DNS CRL

Distribution point
Trigger to retrieve new CRL
… or an internal trigger for a

new CRL
Read CRL FQDN from

certificate
DNS query
(CRL Server FQDN)
DNS response
(CRL Server IP@)
CRL retrieval procedure
For internal use

• The NE implements a DNS client

– The implementation is generic and not tied to the CRL server address
– This feature implements DNS client functionality only in eNB
– Later on the DNS could be used for resolving addresses of other O&M network services like OMS IP address
(not in scope of this feature)
• DNS server
– A standalone 3rd party network entity
– OMS or NetAct are not expected to provide DNS service
– Server can be located in NetAct or OMS site
• DNS protocol
– UDP and TCP used for DNS protocol
– RFC1034, RFC1035
– Reverse lookup (resolving FQDN with an IP@) is not required
• CRL Distribution Point protocol
– LDAP
• Abnormal conditions
– Primary DNS server is unavailable
 Secondary DNS server is attempted (if configured)
– Both primary and secondary DNS servers are unavailable
 The NE continues the retrials till the problem is corrected
For internal use
Main Menu
Table of Contents



Deployment Aspects
For internal use

Abbreviated name: Full name:

dnsAccessId DNS servers access configuration identifier
MO class: Full description:
IDNS
Structure: This parameter identifies the DNS Access configuration object. Value is always 1.
Range and step: Comment:

1...1, step 1
PDDB default value:
-
For internal use


serverIpAddress IP address of the primary DNS server
IDNS
This parameter specifies the IP address of the primary DNS server. If the parameter has a valid value (not
Structure:
empty, not 0.0.0.0) this server is queried first for DNS resolution.

7...15
PDDB default value:
-
For internal use


serverIpAddress2 IP address of the secondary DNS server
IDNS This parameter specifies the IP address of the secondary DNS server. The secondary DNS is queried if the
Structure: IP address of the primary DNS server is not configured or if it is configured but a query for DNS resolution
to the primary DNS server fails.
7...15
PDDB default value:
-
For internal use

Main Menu
Table of Contents



Deployment Aspects
For internal use

• The feature is not licensed (no activation needed).

– The proof of the successful configuration is that the NE retrieves the new CRL when ordered – no alarm
– DNS queries can be monitored from the IP messaging
– The DNS server is connected to the O&M DCN and configured with the CRL Distribution point FQDN and IP
address
– The CA in configured so that the CRL Distribution Point FQDN is provided in the certificates instead of the IP
address
 The NE supports both alternatives
– The IP address of the DNS server is configured in the NEs
– The firewalls of the system is configured to allow DNS traffic
– The certificates are revoked in order to initiate the DL of new certificates with CRL server FQDN
 In operator network this is not needed as long as the IP@ of the CRL server is not changed
• Feature is deactivated when the CA is configured so that the CRL Distribution Point IP address is again provided
in the certificates.
For internal use

• Another feature is needed for this one:

– LTE665 – LTE Certificate Management
– LTE685 – Infrastructure for Certificate Authority (CA) and Registration Authority (RA)
• This feature is needed for:
– LTE523 – Multi-layered Certificate Authorities
 Having multiple CAs in the infrastructure means multiple CRL distribution servers
 DNS makes the solution more flexible
– LTE595 – Transport Separation for RAN sharing
 The separation of transport per operator may require separate CAs, thus supporting CRL retrieval from different locations
 DNS makes the solution more flexible
• Another feature is affected because of this one:
– LTE154 – LTE BTS Auto Connectivity
 Until the DHCP support for retrieving the DNS server IP addresses is implemented (not in this feature), the CRL cannot be
downloaded before the secure connection to OMS
 However, this does not prevent the auto-connection to work, because the certificate validation against the CRL is skipped if
no CRL is available
 Unnecessary alarm until the CRL is successfully downloaded in later phase after the auto-configuration with DNS server IP
parameters
For internal use

• The following requirements are not closely related to the LTE482: DNS Support for Certificate Examination
feature, but should be taken into account when selecting a DNS server for the network:
– Place DNS server on the demilitarized zone. The DMZ should be located between the network elements and
the NetAct.
– Use authentication ticketing for DNS services.
– Restrict zone transfers to minimize the amount of information on the network available to attackers. Consider
the authenticated zone transfers if zone transfers are required.
– Use two servers, or the views feature, if internal and external clients require different information (so-called
split-horizon or split-brain technique). For additional security, consider using DNS proxying for the external DNS
server.
– Internal DNS servers should be recursive, and external DNS servers must be non-recursive.
– Do not allow dynamic updates. If dynamic updates are required, use transaction signatures to authenticate
requests.
– If the system does not serve as a DNS server, ensure that no DNS service is running.
– Run DNS server in a chroot (change root) environment, and run it without super-user privileges.
– Run DNS on a dedicated server.
For internal use

Main Menu
Table of Contents



Deployment Aspects
For internal use

Benefits and Gains Table of Contents Main Menu
• Efficiency, quality, reliability

– OPEX savings when revocation repository server address is changed
 Instead of changing the IP address of the revocation repository in each certificate, only DNS server needs
to be updated with new address
 The certificates includes Full Qualified Domain Name instead of IP-address for the certificate revocation
repository server
– Capability to deploy a multi-layered Public Key Infrastructure for the own network and to cross-
sign with Public Key Infrastructures of other operators.
For internal use

Main Menu
Table of Contents



Deployment Aspects
For internal use

• There are no counters related to this feature.

• There are no key performance indicators related to this feature.
For internal use

Main Menu
Table of Contents



Deployment Aspects
For internal use

References Table of Contents Main Menu
 CFAM LTE482 DNS Support for Certificate Examination, System Feature Specification,
Version 1.1.0, T. Kinnunen
 LTE Radio Access, Rel. RL30, Operating Documentation, Issue 01
 LTE482 - DNS Support for Certificate Examination.ppt, Feature Introduction
 LTE482 DNS Support for Certificate Examination, Focal Point
 LTE482 DNS Support for Certificate Examination, PKDB
For internal use


3014 Pre

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

3014 Pre

Hochgeladen von

Copyright:

Verfügbare Formate

IKEv2 Signaling, IKE SA and IPSec SA setup Table of Contents Main Menu

LTE689 – LTE IPSec Support

IKE_AUTH request (encrypted)

Creates CHILD SA:

For internal use

UE eUu eNB S1 MME eNB eNB

S1-AP signaling X2-AP signaling

NOTE: S-plane security not specified by 3GPP

For internal use

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

• TS 33.401 – Security Architecture

• TS 33.310 – Authentication Framework

*) for un-trusted networks

NEI Contact: Dominik Dulas, Roman Arcea

For internal use

• FTLB implements an IPSec security gateway to enable site-to-site VPN.

For internal use

• Security parameters for IKE SA of the policy:

• Security parameters for child SA policy (ESP tunnel mode):

• IPSec tunnel (IKE SA tunnel) parameters:

For internal use

Parameter XML Name DB object Value range Default Description

AES_128_CBC (1), 3DES_192_CBC

NEI Contact: Dominik Dulas, Roman Arcea

For internal use

Certificate Server • Registration Authority RA

For internal use

For internal use

Trigger: A new installed eNB wishes to initialize the operator’s PKI:

Identity Management Operator Certification

Generate key pair

decrypts CA signed cert with vendors device private key

For internal use

For internal use

For internal use

• To prevent hanging SAs, Dead Peer Detection has been specified

For internal use

For internal use

Introduction Configuration Management

Interdependencies Dimensioning Aspects

Technical Details Performance Aspects

Deployment Aspects References

NEI Contact: Radoslaw Ruchala, Roman Arcea

For internal use

For internal use

For internal use

Non-blocking throughput performance with IPSec

FTLB – Schematic Interfaces and Subnet Overview

private net public net

Soc Classification level

For internal use

Non-blocking throughput performance without IPSec

For internal use

Non-blocking throughput performance without IPSec

FTIB – Schematic Interfaces and Subnets Overview

− IPSec processing done jointly

private net public net

For internal use

Introduction Configuration Management

Interdependencies Dimensioning Aspects

Technical Details Performance Aspects

Deployment Aspects References

NEI Contact: Radoslaw Ruchala, Roman Arcea