secure from go: stoke guide to securing lte networks from day 1

WHITE PAPER

Secure from Go

Best Practices to Confidently Deploy and Maintain Secure LTE Networks

January 2014

Secure from Go


Stoke, Stoke Session Exchange and the Stoke logo are trademarks of Stoke, Inc. Copyright © 2014 Stoke, Inc. All rights reserved. Lit# 130-0028-001 2

Contents Introduction ...................................................................................................... 4

Part I: Why Protect the LTE Network from the Outset? .................................. 5

3GPP Recommendations for Untrusted Domains ........................................ 5

How Secure is Private Backhaul? ................................................................ 6

Malicious (Unauthorized) Access ................................................................. 6

Interception at the Cell Site ....................................................................... 7

Small Cell Vulnerabilities ........................................................................... 7

Service Disruption ........................................................................................ 8

VoLTE Raises the Bar .................................................................................. 9

Lifecycle of the Security Gateway ................................................................ 9

Part II: Best Practices to Successfully Deploy and Maintain the Security Gateway ........................................................................................................ 11

Designing the Security Gateway ................................................................ 11

Design Considerations ............................................................................ 11

S1 Security Functions: Best Practice Recommendations ...................... 12

Capacity: Best Practices Recommendations ......................................... 13

High Availability: Best Practices Recommendations .............................. 15

Verification and Acceptance Testing .......................................................... 17

Performance Tests: Best Practice Recommendations ........................... 17

Standalone Test: Best Practice Recommendations ............................... 19

Functional Tests: Best Practice Recommendations ............................... 20

Network Integration Tests: Best Practice Recommendations ................ 23

eNodeB Variances in IPsec Implementation ........................................... 23

Secure from Go



Deployment and Final Acceptance ............................................................. 24

Site Survey .............................................................................................. 24

Installation Method of Procedure (MOP) Development ........................... 25

Equipment Installation, Verification, and Hand-off .................................. 26

Operating and Maintaining the Security Gateway ...................................... 26

Knowledge Transfer ................................................................................ 26

Network Management ............................................................................. 27

Conclusion: Secure at Launch with a Proven, Scalable Solution ................. 28

The Stoke Security eXchange ....................................................................... 29

Contact Stoke ............................................................................................. 30

Secure from Go



Introduction Fuelled by consumer demand and recent events, the trend towards operator adoption of IPsec security

is rapidly increasing, and the operator question of whether to secure the Radio-to-Core (S1) interface in

LTE deployment has now turned to how to most effectively enable those deployments.

Stoke has engaged with numerous mobile network operators (MNOs) around the world to deploy their

Radio to-Core security infrastructure and in their decision process for security gateway (SEG)

components. In instances where the MNO has opted to use an IPsec- appliance designed for enterprise

networks, picked an add-on solution from among its current suppliers, or left the decision late in the

design cycle, the results have been consistently disappointing:

x More Complex Interoperability Issues: Initial testing reveals interoperability issues between

eNodeBs and SEG, adding pressure to already compressed deployment schedules;

x Inadequate Capacity due to Increased Traffic Loads: As the challenges of increasing traffic

loads and performance requirements become manifest, the initial selection struggles to cope

and/or becomes expensive in the long run as more equipment must be added.

x Unpredictable Signaling Peaks: Tier 1 providers have experienced service-impacting outages

related to anomalies in applications or network nodes, causing excessively high signaling level

The LTE S1 link (between the RAN and EPC) is a new domain, different to all other network interfaces

where add-on security is applied. Network elements developed for the SGi (Core to Internet) or S8

(Operator-to-Operator) interfaces have unique capabilities within that environment, but do not possess

the processing capacity, low latency, flexibility, and interoperability needed at the specific location of the

S1 link. The S1 interface carries all data plane traffic and critical control plane traffic and the Security

GW is the only network element with aggregate visibility into both. Control of this interface can protect

EPC elements from signaling overload resulting from extraordinary operating conditions or from

malicious attack.

In this white paper, Stoke offer guidelines about the criteria for selection of an LTE security solution, and

provide detailed deployment and testing criteria to help operators avoid such issues. This paper

provides insight into why and how operators successfully secure their LTE networks from initial LTE

launch, including best practice guidelines for designing, testing, and deploying the LTE security gateway

(SEG). Part I describes LTE network vulnerabilities and threats and the rationale for securing the S1

interface from launch. Part II provides design, test, and deployment recommendations, based upon

Stoke’s combined experience with multiple security gateway deployments.

Secure from Go



Part I: Why Protect the LTE Network from the Outset? The industry is now universally aware that LTE networks are far less secure than 3G: aside from a

paradigm shift towards the use of vulnerable all-IP transport networks, , the higher layer protocols, their

specification, vulnerabilities and open source implementations allow greater access to the would-be

attacker. In a recent report, Heavy Reading has forecast that the percentage of LTE cell sites protected

thru IPsec will more than double in 2015, and exceed 50% of the end of 2017.1

Operators are demonstrating their realization that the flatter LTE architecture introduces new and

different challenges and that the security gateway (SEG) – the lone sentry at the border between the

RAN and core network– is needed to provide encryption as well as other protective features to keep the

network safe.

3GPP Recommendations for Untrusted Domains

With the migration from circuit-switched networks to packet-switched networks (GPRS) as well as the

use of IP transport in general, 3GPP has recognized the need for enhanced protection to traffic running

over these networks and associated interfaces. 3GPP has therefore developed specifications for how IP-

based traffic is to be secured over the interfaces in the access/transport networks (E-UTRAN), in the core

network (EPC), and/or between two or more core networks, in the event that any of these networks or

the backhaul between them is “untrusted”.

3GPP specifies the placement of a Security Gateway (SEG) to concentrate and protect all traffic entering

or leaving the security domain, at the border of these defined security domains, in TS 33.210. This

includes the RAN-EPC (S1 interface). The method by which the protection mechanisms are

implemented is provided via IPsec, specifically IPsec Encapsulating Security Payload (ESP) in tunnel

mode, with IKE (Internet Key Exchange) used to setup IPsec security associations between SEGs or

between SEG and other network equipment.

1 Heavy Reading, Ethernet Backhaul Tracker, June 2013.

Secure from Go



Figure 1. 3GPP recommends s security gateway and the RAN-core border.2

IPsec ESP provides for three levels of security protection each with a wide set of available security

algorithms:

x Confidentiality – provided via IPsec cryptographic packet encapsulation (e.g. AES).

x Integrity – provided via IPsec cryptographic packet hashing mechanisms (e.g. SHA-2).

x Authentication – provided initially via secure key exchange and mutual authentication between

SEGs or SEG and network equipment using the IKE protocol, pre-shared keys (PSK) or public

key infrastructure (PKI).

How Secure is Private Backhaul?

Even though 3GPP standards require IPsec encryption when backhaul is untrusted, operators are left to

determine the trustworthiness of their backhaul or whether or not to adopt the 3GPP recommendations.

This is a difficult task in a rapidly evolving security environment. For example, private backhaul has long

been considered a “trusted” link for RAN-core and inter-data center communications, consequently

many mobile carriers and large enterprise have previously considered it unnecessary to secure the traffic

carried over private backhaul. When this is applied in LTE networks, it means that traffic will be

transmitted as “clear” (not encrypted) over the mobile access border (between the eNodeB and the

EPC). Recently, however, it has become apparent that backhaul interconnection points or even an

internal network cloud is also vulnerable to interception of user data by government sources or

sophisticated hackers.3

Malicious (Unauthorized) Access

Wherever there is clear text transmission, there is significant security exposure.

2 Senza Fili Consulting, “The Widening Role of the Security Gateway”. 3 Washington Post, “How the NSA is infiltrating private networks”, October 30, 2013.

Secure from Go



In LTE networks, if an attacker can intervene at the cell site, backhaul interconnection point, or at any

other point on the S1 or X2 interface, he can gain access to the clear text and potentially to the larger

network, i.e. access to the private subscriber transmissions (user plane) as well as access to EPC

resources through the control plane.

Access through the network, or over-the-air from the device was not a concern in the proprietary 3G

network. Physical intrusion or vandalism of a cell site would be limited to a localized outage or service

degradation. However in LTE networks, by gaining access to an individual eNodeB/ HeNodeB or to the

backhaul links at a site, physically or through a smartphone, a hacker can spoof eNodeB credentials and

potentially gain direct access to the entire packet core.

Interception at the Cell Site

Once an unauthorized device has “spoofed” eNodeB credentials and gained access into the core, a

hacker can initiate a number of different attacks on both the control plane and the user plane that

potentially impact a much broader service area or even the entire network:

x Control Plane Denial of Service (DoS/DDoS): Injecting large volumes of signaling traffic (SCTP)

or malformed and invalid S1-AP messages can overload the MME, slowing connection times or

making MME resources unavailable for other services.

x User Plane Denial of Service (DoS/DDoS): Injecting large volumes of GTP traffic into the user

plane can overload the serving gateway (SGW).

x User-Plane Packet Injection: Malware or other malicious software can be added to user plane

traffic destined for a number of EPC elements.

x Packet Interception (Eavesdropping): User data can be intercepted and financial credentials or

other private user information stolen.

x Packet Modification (Man-in-the-Middle): Changing user or control plane data can result in

unbilled and unauthorized rogue use of the network.

Small Cell Vulnerabilities

Security requirements for small cells first surfaced with the introduction of femtocells into 3G networks.

In the case of mobile network traffic traversing unsecured fixed line network connections for

backhauling to the mobile core, 3GPP demands that those links be encrypted.4 For LTE, encryption is

likewise required for small cells and femtocells leveraging the unsecured Internet for backhaul.

4 See 3GPP TS 33.310 and 33.821

Secure from Go



Small cells, situated in public venues or homes, are more vulnerable to physical tampering and have less

physical security than macro cells. With numbers expected to exceed 700,000 worldwide by end of

20175, physical security similar to macro cells is cost prohibitive or impractical. Operators have

struggled to keep up with the security risks.

Service Disruption

While IPsec and strong authentication prevent the vast majority of EPC intrusions, non-malicious events

can occur and can cause equally disruptive denial of service conditions.

In addition to damage from malicious hackers, poorly configured, over-the-top applications or localized

outages have been proven to create signaling spikes that overload networks elements so much as to

snowball into large-scale network outages. These signaling spikes occur within legitimate S1 protocols

and can occur even when transmitted securely within the IPsec

tunnel. These denial of service conditions are unexpected, not

predictable, and often the result of unintentional or routine

actions by users and operators. All of the following well

publicized outages were unexpected and costly to mobile

operators:

x A routine software upgrade initiated a signaling storm

and caused an 18 hour outage and cost $18M.

x A popular Android application loaded the network with control signals (even when users were

inactive) and prompted a $2.1B network capacity upgrade.

x Network upgrades of different EPC network elements have been a common factor in multiple

LTE network outages.

Other potential threats have also been identified including:

x Localized service outages could cascade to larger portions of the network as large numbers of

eNodeB’s attempt to reconnect.

x eNodeB malfunctions could send malformed or out of order packets or large streams of

connection requests, overloading core resources.

High signaling traffic loads and unexpected surges impact multiple interfaces in LTE networks, but LTE’s

flatter network architecture (without an RNC) exposes the Mobility Management Entity (MME) and

5 Source: Heavy Reading

Figure 2. Sources of service disruption.

Secure from Go



System Design

Verification /Acceptance

Testing

FOA

System Rollout

Training / Knowledge

Transfer

Technical Support Services

magnifies the impact of any interruption of MME service. Signaling capacity has become a critical

consideration when dimensioning MMEs and other core elements. The security gateway guards the

border to these expensive assets, protecting the EPC.

VoLTE Raises the Bar

Service disruption is not an acceptable option for LTE consumers. Having initially suffered through

dropped calls and spotty service with 2G and 3G networks, users will minimally expect the same quality

of voice and data than they now enjoy with 3G, and have high hopes for LTE in terms of better data

and voice call quality. There’s a general expectation that consumers will able to distinguish VoLTE

(Voice over LTE) to VoLTE calls versus any others just from the audio quality during the conversation.

This quality of voice will be the key differentiator for operators as they roll out VoLTE service in

competition with over-the-top VoIP service providers.

Infonetics Research saw 12 commercial VoLTE networks in operation by year-end 2013, with an

estimated 8 million subscribers - about three-quarters of those in Asia Pacific. The rest of the world is

catching up fast. Balancing security and timing is therefore starting to become a key part of the VoLTE

debate and standards bodies are currently looking at the issue. In the US, the Department of Defense

requires encryption for mobile voice and data.6 That means operators have to care about security and

throughput. Overall, VoLTE is driving a great deal more conversation in the industry about security and

encryption.

Operators are now focused on how they can make quality of service, and the addition of value-added

new services coexist with the heightened global emphasis on securing LTE networks, and how security

mechanisms can coexist with the requirement to keep latency at the

lowest possible levels.

Lifecycle of the Security Gateway

When deploying a security gateway, operators must consider

requirements for every phase of the deployment lifecycle. For

example, during the design phase, system level and device

configuration details are worked out. Multiple stages of testing next

occur, in the laboratory and then in the first office application.

Subsequently, the system is deployed in the live network, with

6 DOD Directive 8100

Figure 3. The Security Gateway Lifecycle

Secure from Go



complete system commissioning and final acceptance testing.

Finally, routine maintenance and technical support becomes an ongoing requirement.

With an experienced security gateway vendor with expertise in IPsec, eNodeB integration, and IP

networking and support for comprehensive testing and integration procedures, the operator can include

the security gateway with little-to-no impact on the overall LTE deployment project schedule.

In Part II of Secure from Go, design, test, deployment and support issues are explored and best

practices defined that will enable operators to successfully and confidently deploy the LTE security

gateway at network launch.

Secure from Go



Part II: Best Practices to Successfully Deploy and Maintain the Security Gateway

Designing the Security Gateway

The design stage consists of both high level and low level design and results in the “golden

configuration” that will be deployed in the network and verified at final

acceptance testing. The high level design defines the capacity and

functional requirements and network interfaces that the security gateway

must support. The low level design provides configuration details, port

assignments, IP addresses, site locations, policy rules and other details

needed to complete integration into the network.

High Level Design should ensure needed confidentiality, integrity,

authentication, availability and sufficient capacity for the network lifecycle.

It should support traffic and subscriber growth, changes in network

services and traffic characteristics, and seamlessly interoperability with

eNodeB and EPC elements.

Design Considerations

Traffic demand in mobile broadband networks is extremely difficult to forecast accurately. Stoke has

observed marked differences in operator LTE capacity forecasts, even with similar subscriber base. Based

on deployments and discussions with multiple operators, Stoke recommends that operators consider the

following factors in preparing their high level designs:

x Magnitude Shift in Capacity Requirements: The combination of new devices, higher speeds,

new bandwidth hungry applications, have created nearly unpredictable usage and adoption

patterns and left operators with few viable tools for accurate forecasting. Operators need to

assume that growth could ramp up very quickly with much larger traffic surges and should

factor in additional capacity as insurance against this uncertainty.

x Significant Changes in Traffic Characteristics: Real-time services such as VoLTE and

streaming video require latency, high processing from all network elements. The security

gateway, which handles the processing intensive function of encryption/decryption must be

able to support very low latency and ultra-high packet processing.

x Signaling Increases: Control plane (signaling) traffic is essential to efficient functioning of the

Secure from Go



network. If signaling is disrupted or excessive, service disruption or degradation may occur.

Average signaling is increasing in LTE networks due to chatty applications, more frequent

mobility events with small cells. Signaling peaks can also occur and have been known to cause

network outages.

S1 Security Functions: Best Practice Recommendations

The high level design needs to assure compliance with requirements for confidentiality, integrity,

authentication, and availability. This includes defining the following IPsec related security elements:

Function Purpose Recommended Best Practices for SEG

Internet Key

eXchange

Internet Key Exchange (IKE/IKEv2) is

used to securely negotiate, create

and manage the Security

Associations (SAs) that define the

values used by IPsec to encrypt and

protect packet transmissions

between the RAN and the SEG.

IKEv2 has several advantages over IKEv1 such as:

x Faster tunnel negotiation and setup

x Native support for NAT Traversal (NAT-T)

x Native support for tunnel liveliness detection (DPD –

Dead Peer Detection)

x Support for EAP-based authentication mechanisms

x Reliability and State Management (use of sequence

numbers and acknowledgements)

Encryption

Algorithms Provide strong data confidentiality

SEG must support a wide number of standard encryption

algorithms

Hashing

Algorithms

Provide integrity protection and

authenticity

SEG must support a wide number of standard hashing

algorithms

Figure 4. Recommended IPsec functions required in SEG.

The authentication mechanism must also be determined. Stoke recommends PKI (public key

infrastructure) be added with certificate management protocol.

Secure from Go



Authentication Purpose Recommended Best Practices

Pre-Shared Key

(PSK)

Authentication

In Pre shared key (PSK), the key

is shared and stored at both

endpoints, and operators must

ensure keys are regularly

changed.

While generally supported and easy to implement, PSK can

be burdensome when attempting to change keys on a

large network.

Public Key

Infrastructure

(PKI)

Authentication

PKI is an ecosystem which

provides methods to request,

create, manage, store, distribute,

and revoke digital certificates.

PKI eliminates the major disadvantages of pre-shared key

(PSK) mechanisms that are more commonly used by mobile

operators today – that is, the operational burden imposed

when modification of static keys is necessary on potentially

thousands of network elements

PKI requires a unique certificate for each device, so should

be used with an automated certificate provisioning,

renewal, and revocation process, such as with a Certificate

Authority solution

Certificate

Management

Protocol (CMPv2)

For ease of deployment and

management, Stoke

recommends the use of CMPv2

and Certificate Revocation List

(CRLv2).

When CMPv2 is configured on the SEG, the SEG acts as a

CMPv2 client and communicates through HTTP or HTTPS

with the Certificate Authority (CA) or Registration Authority

(RA) that operates as a CMPv2 server.

Certificates Robust certificates ensure only

authorized access

The most robust authentication mechanisms and

certificates (Diffie-Hellman group 14, 2048-bit

authentication and X.509 certificates) ensure only

authorized access.

Figure 5. Authentication mechanisms purpose and recommendations.

The SEG should securely aggregate and authenticate a growing body of sites, traffic, and subscribers

while still sustaining high throughput per session. The next section describes best practice

recommendations for determining capacity requirements.

Capacity: Best Practices Recommendations

Proper scaling of the security gateway can enhance network performance by aggregating control and

user plane traffic from eNodeB, including mixed RAN and HetNets, performing the needed security

Secure from Go



function without adding any appreciable latency and providing a guard against signaling overload

conditions. Stoke recommends that operators include the following parameters when evaluating

capacity requirements and capabilities for security gateway:

Parameter Description Comment

Gigabits per second (Gbps)

Total, bi-directional aggregated throughput (clear

and encrypted) that the SEG will be required to

sustain, across a broad range of packet sizes

Vendor calculations vary

widely and need to be

normalized for comparison

Encrypted Packets per Second (PPS)

(packet arrival rate)

The packet arrival rate into the SEG. Defines the

equipment’s packet processing and forwarding

limits for encrypted (e.g., IPsec) packets

Real-time services such as

VoLTE are characterized by

small packet size, which

increases PPS capacity

requirements for SEG

Latency

Time it takes for a given network packet to travel

through the network equipment, from source to

destination (in microseconds)

For the SEG, latency should

be less than 50

microseconds

Figure 6. Recommended parameters for defining SEG capacity.

Both Gbps and packets per second (PPS) are performance metrics that impact scalability and cost, and

their impact should be understood by the operator. By identifying the maximum PPS, operators can

better understand how the equipment will perform under the full range of peak traffic conditions and

packet sizes found in the network, and how quickly network equipment will need to be augmented to

sustain network throughput as average traffic characteristics change.

The maximum encrypted PPS defines the equipment’s packet processing and forwarding limits for

encrypted (e.g., IPsec) packets. As packets for a given data volume get smaller, the packet arrival rate

increases and more packets must be simultaneously forwarded by the equipment within a given period.

Additionally, when IPsec is added, the equipment must also manage the processor heavy encryption or

decryption duties before forwarding the packets.

The figure below illustrates a mathematical calculation on theoretical maximum and does not include

other equipment design limitations that can impact the actual packets per second that an operator

would achieve.

Secure from Go



Figure 7. Theoretical maximum packets per second, by packet size.

Equipment with a higher encrypted PPS can encrypt/decrypt higher arrival rates of incoming packets

and forward them more quickly, without introducing latency or dropping packets. If the incoming

packet arrival rate exceeds the PPS processing limits of the equipment, packets will be dropped or

delayed, causing retransmission or additional latency. Throughput will decline and additional capacity

may be required to sustain the desired performance.

High Availability: Best Practices Recommendations

Operators should consider availability and recovery for multiple types of failures and weigh the costs of

protection against the risk and frequency that the failure may occur. For example, internal software

bugs are the most commonly occurring incidents that could lead to potential failure, but can be

prevented with a hardened, well tested security gateway and operating system. In contrast, failure of

the SEG chassis itself or of an entire site (such as in a natural disaster) is the least likely to occur and the

most expensive to protect, as system duplication at a separate geographic site is required. This is

summarized in the table below.

Secure from Go



Incident Type Risk/ Frequency Relative Cost

Software (Bugs) High Lower Cost

Higher Cost

Link Medium

Card / Component Medium

Chassis Low

Site Low

Figure 8. Failure types, frequency and relative cost to mitigate.

The security gateway and overall network architecture should provide four layers of high availability

features, addressing each potential failure types.

Layers of High Availability Failure Type Recommended SEG Features

Operating System Resiliency Software Redundant software processes

Intra-chassis Resiliency

Link Port Level Redundancy

Card / Component

N:1 Line Card Redundancy

System Component Redundancy

Inter-chassis redundancy (ICR) - Single Site Chassis

Synchronized IPsec Tunnel State

with stateful IPsec session preservation

Active/Active Configuration

Active/Standby Configuration

Single or Multi-Site Options

Inter-chassis redundancy (ICR) - Multi Site Site

Figure 9. Recommended high availability features.

Inter-Chassis Redundancy (ICR) feature set should provide a stateful IPsec session protection, and a

completely transparent, hot-standby system switchover in the event of a major component failure within

an ICR domain. When comprised of an Active-Standby pair of identically configured SEG chassis, the

ICR configuration continuously synchronizes IPsec tunnel state information between chassis, which

allows for session recovery and a seamless, transparent switchover between chassis.

In addition to Inter-Chassis Redundancy (ICR) and many intra-chassis resiliency and mechanisms, the

following protocols and mechanisms for high-available SEG operation should be supported.

Secure from Go



Protocol / Mechanism Description Benefit

Bi-directional Forwarding Detection Network Protocol (BFD)

Provide a quick hello-based failure

detection service to routing protocols and

other applications

Faster network connectivity

failure detection

capabilities

Link Aggregation Group (LAG) (IEEE 802.3ad)

A method of grouping ports together in

case of heavy traffic or network failure. Increased system resiliency

In-Service Software Upgrade (ISSU)

Allows an upgrade on a chassis without

removing the entire chassis from service

Lower operating costs and

higher system availability

Figure 10. Additional high availability options.

Verification and Acceptance Testing

The purpose of testing is to identify and correct any interoperability issues,

network anomalies, and hardware or software issues and ensure that the security

gateway will function as expected and integrate into the live network seamlessly.

Initial testing is usually conducted in the laboratory and ensures compliance with

operator specifications and design. These tests include stand-alone functional,

and performance tests. The First Office Application repeats all or some of the

laboratory testing, and adds network integration tests to verify the golden

configuration and ensure interoperability with other network elements.

Additional final acceptance testing may occur when deployment is completed, to

ensure total site integration and interworking with alarm and other support

systems.

The following sections provide details on recommended tests.

Performance Tests: Best Practice Recommendations

Performance testing for the security gateway should find throughput and latency of bi-directional traffic,

over the full range of packet size and sessions that could be encountered in the live network, including

all capacity scenarios anticipated. This testing usually is conducted in the operator laboratory. A

summary of the general procedure as well the minimum set of performance tests follows in the next

two figures.

Secure from Go



Performance Test Summary

Preconditions x Device under Test (DUT), traffic generator, and Radius server are preconditioned

for the required sessions

x AES-128/256/SHA-2 Encryption

x Authentication using RADIUS EAP-SIM

Reference RFC2544

General Procedure x Bring up required sessions on the SEG using the defined encryption suite and

radius authentication.

x Follow RFC2544 and generate traffic from traffic generator for > 2 minutes.

x Calculate throughput and latency using RFC2544.

Figure 11. Purpose and general procedure for performance testing.

A best-of-breed security gateway should be able to sustain line rate throughput with no packet loss and

latency less than 40 microseconds.

Performance Test Minimum Sessions Frame Size Pass Criteria

Latency and Throughput

16k (min) up to 180k

96 Byte

Find clear traffic throughput with a loss

of 0.000% for over 2 minutes.

256 Byte

IMIX7

4,000 64 Byte

9,000 Byte

Traffic routed between 2

line cards 4,000 96 Byte

Bring up Time

(no on-going traffic) 4,000

N/A

Find time taken to bring up 4k sessions

when there is on-going traffic.

Bring up Time

(with on-going traffic) 4,000

Find time taken to bring up 4k sessions

when there is no on-going traffic.

Figure 12. Performance test parameters.

The following table illustrates best practices results from the minimum performance tests.

Frame Size Direction PPS % Clear % Encrypt. Tx Frames Rx Frames Loss % Latency (µs)

64 Byte DUT to Initiator 7,859M 52.81 89.27 951M 951M 0.000 <40

Initiator to DUT 7,859M 52.81 89.27 951M 951M 0.000 <40

7 IMIX calculated at: 58% 64 bytes, 34% 594 bytes, 8% 1518 bytes

Secure from Go



Frame Size Direction PPS % Clear % Encrypt. Tx Frames Rx Frames Loss % Latency (µs)

96 Byte DUT to Initiator 7,183M 66.66 99.99 1,293M 1,293M 0.000 <40

Initiator to DUT 7,183M 66.66 99.99 1,293M 1,293M 0.000 <40

256 Byte DUT to Initiator 3,742M 82.63 99.99 452M 452M 0.000 <40


IMIX DUT to Initiator 2,809M 85.82 98.85 340M 340M 0.000 <40


9,000 Bytes DUT to Initiator .1376M 99.27 99.90 16.6M 16.6M 0.000 <40

Initiator to DUT .1376M 99.27 99.90 16.6M 16.6M 0.000 <40

Figure 13. Best Practice Performance Results

Standalone Test: Best Practice Recommendations

Standalone tests are conducted in the laboratory and should verify that the hardware and software is

performing as expected. These tests do not require interconnection with other network elements. While

these tests can vary depending upon the vendor equipment, the figure below describes the typical tests

that should be conducted.

Test Purpose Pass Criteria

POST System

Initialization

Verify the Security Gateway completes a

power on and self-test.

Everything is in working order and the SEG

boots normally. When the SEG boots

normally, the prompt appears and the

system is ready.

PEM Resilience

Verify that if a single Power Entry Module is

switched off then the system remains working

on the spare unit.

System remains functioning throughout test.

System correctly displays PEM on/off

message. System correctly displays PEM

removed/inserted message.

Fan Resilience

Verify that if a single Fan Module is switched

off then the system remains working on the

spare unit.

System displays correct message.


Remaining fan unit continues to run.

IP Management

Card Resilience

Verify that with removal of one IMC, the

system remains working on the spare unit

System displays correct message. System

remains functioning throughout test.

Secure from Go



Test Purpose Pass Criteria

Line Card

Resilience

To test that if a single line card is removed,

no other line cards are affected. System remains functioning throughout test.

Reload Standby

IMC

Verify that if a standby IMC is restarted,

comes back to Running (Standby) state. System remains functioning throughout test.

Reload Line Card Verify that if a line card is restarted it comes

back to running state.

Line card reloads to running state. System

remains functioning throughout test.

Console messages are displayed for the line

card that is reloading

Reload Chassis Verify that if an SEG is restarted it comes

back to running state System reloads to a fully running state

Line Card Port

Activation

Verify that a line card Port can be brought to

a Link State up Condition


Correct console messages are reported

IMC Port

Activation

Verify that an IMC Port can be brought to a

Link State up Condition


Correct console messages are reported

New User

Creation

Verify that a new administrative user can be

created

System remains functioning throughout test,

user is created and login as test user

successful

Save

Configuration

Verify that the configuration from Section 4.1

can be saved on the SEG


Configuration is saved to device

Clear

Configuration

Verify that an active configuration can be

cleared.

System remains functioning throughout test,

configuration is deleted from device.

Load

Configuration

Verify that a configuration can be loaded

from the internal disk.


Configuration is loaded to device.

Figure 14. Recommended standalone tests.

Functional Tests: Best Practice Recommendations

Functional tests are also usually completed in the laboratory and confirm that all the required functions,

Secure from Go



such as the IPsec security, administrative, resilience, system, alarm and control system functions are

performing correctly. The figure below lists the recommended tests for these functions.

Functional Test Summary

IPsec

x Crypto algorithms for IKEv2

x Verify that session can be successfully brought up with Crypto algorithms

x Crypto algorithms for ESP Verify that session can be successfully brought up with Crypto algorithms P1

x IKEv2 SEG as Responder

x IKEv2 SEG as Responder IPsec peer that does not implement IC can establish

x Dead Peer Detection

x Post Fragmentation, ESP packets

x Pre Fragmentation, ESP packets

x Anti-replay, out-of-sequence ESP packets

x CHILD_SA rekey, SEG initiated

x CHILD_SA rekey, peer initiated

Resilience

x HA PLR - (by manual)

x HA PLR – (by command)

x HA 1:x line Card redundancy (manual)

x HA 1:1 line card redundancy (by command)

x Session state and traffic continuity when port on LINE CARD 2 is re-enabled after HA PLR test

x Session behavior and performance not affected during IMC switchover (by manual)

x Session behavior and performance not affected during IMC switchover (by command)

x Session behavior and performance not affected during one PEM failure

Session behavior and performance not affected during one FAN failure

Admin

x User creation

x Password modification

x Command history

x Check current user

x Display user login and logout information

x Remote access configuration (Telnet/SSH)

x Log file management

Secure from Go



Functional Test Summary

System

x Verify OS version

x Verify card status

x Check CPU usage

x Check Memory usage

x Check disk usage

x Check environmental status

x Save and Load configuration

x Backup and restore configuration using external compact flash

Alarm

x Manual PORT Down

x Physically unplug link connecting to the router and check that SNMP trap is send with the link detail

x Pull out Active line card from Slot2 and check that SNMP trap is sent

x Pull out Standby line card from Slot4 and check that SNMP trap is sent

x Pull out the ACTIVE IMC and check that SNMP trap is sent

x Pull out the Standby IMC and check that SNMP trap is sent

x Bring down the IPsec session and check that SNMP trap is send with the information that IPsec session

is down

x Bring down one of the power and check that SNMP trap is send with the information that one power

supply has failed

x Active line card in slot 2 is faulty and need hardware replacement. SNMP Traps are generated

x Active line card in slot 2 port 0 link is down. No SNMP Trap generated.

x Active line card in slot 2 port 1 Primary and Backup links are down. SNMP Traps generated

OS Control

x Session state and traffic continuity during system s/w upgrade

x Session state and traffic continuity during system s/w downgrade

x Unused content

x HA 1:1 IMC Card redundancy

x Debug for existing session

x Debug for new/next session

x Debug for specific processes

x Debug by slot

x Debug by Context

x Show Tech Support

x Display Performance Statistics

x SSH Capability

x Log file management

Figure 15. Recommended functional tests for security gateway.

Secure from Go



Network Integration Tests: Best Practice Recommendations

Network integration tests may be conducted in the network as well as in the network. These tests

should include all network elements with which the security gateway will interface, including the

mobility management entity (MME), eNodeB/HeNodeB, routers, Serving Gateway (SGW), and

operations/administration/management network. These tests should confirm the correct configuration

parameters established in the design phase and enable early correction of any issues.

NI Tests Purpose Pass Criteria

Cabling the Security Gateway

Establish physical connectivity

to the eNodeB, EPC, and

Management networks

Physical connectivity to eNodeB, EPC and Management

network established.

Management Card IP

Connectivity

Configure and verify IMC IP

connectivity to the OAM

network router


Ping to OAM network is successful.

IP connectivity to eNodeB

side network

Verify that the eNodeB

network is reachable

System remains functioning throughout test

Ping to eNodeB network is successful.

IP connectivity to EPC side

network

Verify that the EPC network

is reachable


Ping to EPC network is successful

Static Routes Add static routes to a

context and verify

Non local network destination host is reachable in RAN

and EPC context

Dynamic Routing Verify OSPF adjacency OSPF has established adjacency

IP Sec session configuration To verify an IPsec session can

be brought up IPsec session is created successfully

Line Card redundancy

Verify Line Card Redundancy

provides minimum service

interruption

IPsec session remains active while line card is removed

and reinserted

Figure 16. Network Integration tests purpose and criteria.

eNodeB Variances in IPsec Implementation

IPsec is a mature protocol and widely used in IT infrastructure. However, its adoption as a RAN-core

security mechanism for mobile network infrastructure is relatively recent. As a result, there can be

significant differences among available eNodeB's vendors, even for the basic end-to-end processes

previously described, including the following:

Secure from Go



Observed eNodeB Variances

Authentication Either IKEv1 or IKEv2 are supported by the eNodeB. In a mixed RAN environment, the

SEG may need to support both versions

Initial Contact eNodeB's designed as either a responder or an initiator of the tunnel request

IPsec Tunnels No selective encryption or separate tunnels for control, management, and user plane,

Figure 17. Support for diverse eNodeB parameters.

In mixed RAN networks, interoperability with all eNodeB models should be required. Network

integration tests should include all eNodeBs that will be present in the live network.

Deployment and Final Acceptance

In deployment, the security gateway equipment is installed in all needed

sites. This phase consists of several steps.

x Site Survey

x Material Procurement

x Installation Method of Procedure (MOP) development and

approval

x Equipment Installation, verification and hand-off

Site Survey

A site survey provides the installation partner or equipment vendor with the opportunity to gain a clear

understanding of the site access, conditions, readiness of the target work area, and site specific

guidelines. This also allows an opportunity to verify and if necessary, make corrections the operator

statement of work. The partner documents the following items during the Site Survey:

Category Site Survey Details

Logistical Information

Address confirmation

Entry and Exit access points; Prohibited areas

Work hours

Material and tool delivery and storage

Validate racks and super

structure Determine if auxiliary framing is required

Cable Rack Existing availability

Determine if additional is required

Secure from Go



Category Site Survey Details

Fiber Management

Requirements

Existing availability

Determine if additional is required

General Relay Rack and

Equipment Information

Verify labeling

Identify fuse panel locations

Fuse and Breaker assignments

Available positions

A/C termination areas if required for installation work

Type; Rack location

Grounding Terminations Main, Aisle, Bay; Equipment

Cable (Fiber) Terminations

Main Distribution Frame Termination and Assignments

Fiber FDF Assignments

Miscellaneous Cable Requirements

Cable Hole / Fire stopping ( same floor / multi-floor)

Cable Runs

Available rack space

Alternative run in lieu of cable rack congestion

Identify any current non-compliant issues

Other

Cable Mining and Removal

Miscellaneous Material Requirements

Hoisting and Hauling Requirements

Material Handling

Loading dock access and times

Movement of materials through building (same floor / multi-floor / elevator /

stairs / roof access / hoist to upper floor from street level)

Safety Support Spill Kit on site; Eye-wash station on site

Areas with asbestos; Hard hat area; Exposure to hazards

Figure 18. Site Survey checklist.

Installation Method of Procedure (MOP) Development

The Method of Procedure (MOP) is a detailed list of step-by-step work tasks in a logical order flow. The

MOP identifies critical action items with regard to AC or DC power connectivity, as well as network

critical steps required to be performed solely within a planned maintenance window. Identification of

NOC support is also highlighted in the activity if required.

In summary, the MOP document generally contains the following information:

Secure from Go



MOP Development Included Detail

Activity Description Activity Summary – detailed description of work tasks

Activity Impacts – detail all known impact potential to network reliability

Activity Timeline - planned start and planned completion

Supporting Documents

Technical Specifications

Network Practices

Engineering Design Package

Activity Prerequisites

Materials list

Software and Tools

Technical and non-technical work tasks

Notification Contacts Names of support personnel

Escalations contacts

Other Items Risk Assessment of the defined work

Back Out Plan

Post Activity Validation

Figure 19. Method of Procedure (MOP) work tasks.

Equipment Installation, Verification, and Hand-off

The final major stage is the actual physical installation of the security gateways. As required by the

operator, partner or equipment vendor personnel will remain on-site post-installation to any support

necessary verification or initial testing/commissioning activity that is to be executed by local technicians

or remote NOC personnel. The actual on-site work effort is in compliance with the operator

specifications.

Operating and Maintaining the Security Gateway

Once installation and handover is completed, knowledge transfer must occur,

and then the operator or contracted partner will usually assume responsibilities

for ongoing maintenance, technical support, and upgrades. The security

gateway vendor should remain available to provide technical consulting, Tier 3

technical support, authorizing returns and providing regular upgrades and

support network growth.

Knowledge Transfer

The SEG vendor should provide training appropriate for systems

administrators, NOC personnel, and POP site. In addition, partners and

operators require access to product documentation, instructional videos, and other tools. Stoke

Secure from Go



recommends a thorough knowledge transfer to include the following personnel and curriculum.

x General Administrator: Train-the-trainer, including classroom instruction and on-line access to

documentation and other tools

x System Architecture: Technical training on physical and logical design, system routing, high

availability configuration, scaling parameters and authentication and certificate mechanisms.

x Network Operations: Monitoring and troubleshooting processes, including alarms, trouble

reporting, escalation, and return policies.

x Site Management (POP): General role of the security gateway in the network, basic physical

maintenance, relationship to other network elements.

Network Management

The SEG solution should include a robust intelligent set of operational, administrative, maintenance, and

billing objects, with exposure to a higher order management entities via command line or through a set

of open standard interfaces, plus a comprehensive configuration and monitoring capabilities through a

variety of interfaces, SNMP, Syslog, and CLI.

Secure from Go



Conclusion: Secure at Launch with a Proven, Scalable Solution The business risks for a security breach or service outage are high, but some operators have been

hesitant to add the complexities of IPsec to the long list of technology and operational challenges in

deploying an LTE network, at least at initial launch. However, increasingly subscribers expect the highest

level of security and competitors are quick to exploit any perceived weakness. Also, adding a security

gateway with IPsec at a later date will be more costly and operationally complex, as some re-design of

several other network may be required. More and more, secure RAN-Core backhaul is viewed as a

requirement. Heavy Reading has forecast that the percentage of LTE cell sites protected thru IPsec will

more than double in 2015, and exceed 50% of the end of 2017.

By following the best practice recommendations in this white paper, and using W a proven, scalable

security gateway solution, operators can confidently deploy security solutions that will grow with the LTE

network and protect it from malicious attacks, signaling surges, and other sources of network disruption.

Secure from Go



The Stoke Security eXchange Stoke Security eXchange™ is a cost efficient, carrier grade gateway solution, commercially proven in

public networks to provide the highest level of secure backhaul protection without adding any

appreciable latency. The purpose-built solution is optimized for IPsec and adheres to industry best

practices that recommend separation of IPsec perimeter protection from other Internet firewall

functions. This defense in depth approach provides multiple layers of protection.

Figure 20. Stoke provides best of breed solution for the mobile access border.

Employing the strongest possible encryption and authentication standards, key features include:

x Best of Breed Efficiency: Up to 16 Gbps per rack unit, and as low as 24 watts per Gbps.

x 2048 Bit Certificate Support: Exponentially ensures the validity of security associations between

two network nodes

x Ultra-aggressive Automatic Re-keying: Configurable option automatically resets key, limiting the

amount of data available if a breach occurs.

x Public Key Infrastructure: Eliminates human error of pre-shared key. Perfect forwarding secrecy

(PFS) ensures old keys will not be re-used.

x High Availability: Stateful inter-chassis redundancy and sub-second failover

x Lawful Intercept Support: Secure access for legally required intercept.

Leveraging its strategic location in the LTE network, Security eXchange with Mobile Border Agent

provides a powerful perspective with control plane, user plane, session and RAN visibility that is not

available on other network elements. The Mobile Border Agent conducts stateful analysis of the specific

protocols used in the RAN to EPC border. As an access-agnostic solution, the Stoke Mobile Border

Secure from Go



Agent can also monitor traffic from multiple RAN types, including 3G and Wi-Fi.

The compact, 5 RU chassis provides the IPsec gateway and front-ends the servers connecting each data

center, seamlessly originating and terminating IPsec tunnels and maintaining up to 80 Gbps encrypted

throughput per chassis, even for the smallest packet sizes. The energy efficient solution provides the

highest encrypted throughput per rack unit and per watt of power.

Stoke is a market-proven equipment provider to the service provider industry. The Stoke’s Security

eXchange, employed on the powerful SSX platform is a cost effective solution to achieve the industry’s

highest standard for data center-to-data center secure, high bandwidth communication.

Contact Stoke

For more information on Stoke Security eXchange, please see www.stoke.com or send an email to

[email protected].

http://www.stoke.com/

mailto:[email protected]

secure from go: stoke guide to securing lte networks from day 1

Documents

best practices recommendations

best practice recommendations

secure lte networks

security exchange

gpp recommendations

lte deployment

white paper secure

s1 security functions