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
Best Practices to Confidently Deploy and Maintain Secure LTE Networks
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:
More Complex Interoperability Issues: Initial testing reveals interoperability issues between
eNodeBs and SEG, adding pressure to already compressed deployment schedules;
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.
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:
Confidentiality – provided via IPsec cryptographic packet encapsulation (e.g. AES).
Integrity – provided via IPsec cryptographic packet hashing mechanisms (e.g. SHA-2).
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:
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.
User Plane Denial of Service (DoS/DDoS): Injecting large volumes of GTP traffic into the user
plane can overload the serving gateway (SGW).
User-Plane Packet Injection: Malware or other malicious software can be added to user plane
traffic destined for a number of EPC elements.
Packet Interception (Eavesdropping): User data can be intercepted and financial credentials or
other private user information stolen.
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:
A routine software upgrade initiated a signaling storm
and caused an 18 hour outage and cost $18M.
A popular Android application loaded the network with control signals (even when users were
inactive) and prompted a $2.1B network capacity upgrade.
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:
Localized service outages could cascade to larger portions of the network as large numbers of
eNodeB’s attempt to reconnect.
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:
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.
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.
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:
Faster tunnel negotiation and setup
Native support for NAT Traversal (NAT-T)
Native support for tunnel liveliness detection (DPD –
Dead Peer Detection)
Support for EAP-based authentication mechanisms
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 Device under Test (DUT), traffic generator, and Radius server are preconditioned
for the required sessions
AES-128/256/SHA-2 Encryption
Authentication using RADIUS EAP-SIM
Reference RFC2544
General Procedure Bring up required sessions on the SEG using the defined encryption suite and
radius authentication.
Follow RFC2544 and generate traffic from traffic generator for > 2 minutes.
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
IMIX
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.
Reload Standby
IMC
Verify that if a standby IMC is restarted,
comes back to Running (Standby) state.
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
Crypto algorithms for IKEv2
Verify that session can be successfully brought up with Crypto algorithms
Crypto algorithms for ESP Verify that session can be successfully brought up with Crypto algorithms P1
IKEv2 SEG as Responder
IKEv2 SEG as Responder IPsec peer that does not implement IC can establish
Dead Peer Detection
Post Fragmentation, ESP packets
Pre Fragmentation, ESP packets
Anti-replay, out-of-sequence ESP packets
CHILD_SA rekey, SEG initiated
CHILD_SA rekey, peer initiated
Resilience
HA PLR - (by manual)
HA PLR – (by command)
HA 1:x line Card redundancy (manual)
HA 1:1 line card redundancy (by command)
Session state and traffic continuity when port on LINE CARD 2 is re-enabled after HA PLR test
Session behavior and performance not affected during IMC switchover (by manual)
Session behavior and performance not affected during IMC switchover (by command)
Session behavior and performance not affected during one PEM failure
Session behavior and performance not affected during one FAN failure
Admin
User creation
Password modification
Command history
Check current user
Display user login and logout information
Remote access configuration (Telnet/SSH)
Log file management

Secure from Go
Functional Test Summary
System
Verify OS version
Verify card status
Check CPU usage
Check Memory usage
Check disk usage
Check environmental status
Save and Load configuration
Backup and restore configuration using external compact flash
Alarm
Manual PORT Down
Physically unplug link connecting to the router and check that SNMP trap is send with the link detail
Pull out Active line card from Slot2 and check that SNMP trap is sent
Pull out Standby line card from Slot4 and check that SNMP trap is sent
Pull out the ACTIVE IMC and check that SNMP trap is sent
Pull out the Standby IMC and check that SNMP trap is sent
Bring down the IPsec session and check that SNMP trap is send with the information that IPsec session
is down
Bring down one of the power and check that SNMP trap is send with the information that one power
supply has failed
Active line card in slot 2 is faulty and need hardware replacement. SNMP Traps are generated
Active line card in slot 2 port 0 link is down. No SNMP Trap generated.
Active line card in slot 2 port 1 Primary and Backup links are down. SNMP Traps generated
OS Control
Session state and traffic continuity during system s/w upgrade
Session state and traffic continuity during system s/w downgrade
Unused content
HA 1:1 IMC Card redundancy
Debug for existing session
Debug for new/next session
Debug for specific processes
Debug by slot
Debug by Context
Show Tech Support
Display Performance Statistics
SSH Capability
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.
Site Survey
Material Procurement
Installation Method of Procedure (MOP) development and
approval
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.
General Administrator: Train-the-trainer, including classroom instruction and on-line access to
documentation and other tools
System Architecture: Technical training on physical and logical design, system routing, high
availability configuration, scaling parameters and authentication and certificate mechanisms.
Network Operations: Monitoring and troubleshooting processes, including alarms, trouble
reporting, escalation, and return policies.
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:
Best of Breed Efficiency: Up to 16 Gbps per rack unit, and as low as 24 watts per Gbps.
2048 Bit Certificate Support: Exponentially ensures the validity of security associations between
two network nodes
Ultra-aggressive Automatic Re-keying: Configurable option automatically resets key, limiting the
amount of data available if a breach occurs.
Public Key Infrastructure: Eliminates human error of pre-shared key. Perfect forwarding secrecy
(PFS) ensures old keys will not be re-used.
High Availability: Stateful inter-chassis redundancy and sub-second failover
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
info@stoke.com.

Secure from go: Stoke Guide to Securing LTE Networks from Day 1

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (19)

Similar to Secure from go: Stoke Guide to Securing LTE Networks from Day 1

Similar to Secure from go: Stoke Guide to Securing LTE Networks from Day 1 (20)

More from Mary McEvoy Carroll

More from Mary McEvoy Carroll (6)

Secure from go: Stoke Guide to Securing LTE Networks from Day 1