LTE Security Solution White Paper(20130207)

Published on February 2017 | Categories: Documents | Downloads: 120 | Comments: 0 | Views: 217
of 32
Download PDF   Embed   Report

Comments

Content

Do
c. code

Huawei LTE Security Solution

Issue

Draft B

Date

2015-08-27

HUAWEI TECHNOLOGIES CO., LTD.

Copyright © Huawei Technologies Co., Ltd. 2009. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without
prior written consent of Huawei Technologies Co., Ltd.

Trademarks and Permissions
and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other
trademarks and trade names mentioned in this document are the property of their respective
holders.

Notice
The purchased products, services and features are stipulated by the commercial contract made
between Huawei and the customer. All or partial products, services and features described in this
document may not be within the purchased scope or the usage scope. Unless otherwise agreed by
the contract, all statements, information, and recommendations in this document are provided “AS
IS” without warranties, guarantees or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in
the preparation of this document to ensure accuracy of the contents, but all statements,
information, and recommendations in this document do not constitute the warranty of any kind,
express or implied.

Huawei Technologies Co., Ltd.
Address:

Huawei Industrial Base
Bantian, Longgang
Shenzhen 518129
People's Republic of China

Website:

http://www.huawei.com

Email:

[email protected]

1
1 Executive Summary....................................................................4
2 Introduction.............................................................................. 5
3 Security Solution........................................................................ 7
3.1 Huawei LTE Security Solution Architecture....................................................................................7
3.2 Huawei LTE Security Solution Highlight.........................................................................................8

4 Wireless Security...................................................................... 10
4.1 Integrity Protection...........................................................................................................................10
4.2 Encryption..........................................................................................................................................11
4.3 Keys Generation...............................................................................................................................13
4.4 Initial Security Activation Procedure..............................................................................................14
4.5 Security Activation Procedure during a Handover......................................................................15

5 Transport Security....................................................................17
5.1 Whole-Process Certificate Management......................................................................................18
5.2 Certificate-based Transport Security Mechanism.......................................................................21
5.3 Certificate-Based eNodeB Deployment in Secure Network Solutions....................................25

6 eNodeB Equipment and OM Security..............................................30
6.1 Equipment Security..........................................................................................................................30
6.2 OM Security......................................................................................................................................32

7 Conclusion.............................................................................38
8 Acronyms and Abbreviations.......................................................39

Contents

1

Executive Summary

Security issues have always been the main drawbacks of IP networking, since IP is short on features that are
needed or desirable on insecure network.
Back to 1982, TCP/IP was initially designed for a small network connecting a small community of researchers, but
it gradually became a gigantic global network connecting people of all types. This growth has created problems
with security; TCP/IP protocols, the basis of today's network; lack even of the most basic mechanisms for security,
such as authentication or encryption.
As an all-IP based access technology, LTE naturally inherit of TCP/IP protocols security issues. Therefore, it
needs to be protected against threats that can affect the normal work and communication of the entire network. A
non-secured LTE network could lead to information disclosure, information modification or loss, DoS attack or
even interruption of services.
This white paper introduces Huawei complete LTE security solutions that help you efficiently protect and
guarantee the normal work of your LTE network from the factory phase (eNodeB implementation) to the operation
phase, including installation phase.
The complete security solution is divided into wireless security solution, transport security solution, eNodeB
equipment security solution, and OM security solution; which are wrapped together with the overall solution’s
highlight, and some successful cases to show the solutions maturity.

2

Introduction

Security issues in LTE are drawn from the network structure itself, which is described as follow:
 All-IP network: LTE is using IP protocols that are visible in the eNodeB.
 Flat architecture: the eNodeBs are directly connected to the core network, and this leads to security issues
directly in the eNodeB.
 Provide more data throughput: the more the data throughput, the more the security risks.
 Interworking with legacy networks as well with non-3GPP networks.
 The eNodeB is allowed to be placed in non-trusted locations.
 As the most attractive mobile technology, LTE will embrace new business environments with less trusted
network.
From standardization point of view, confidentiality and integrity protection for signaling and user data is limited to
Uu (interface between an UE and the eNodeB) interface as shown in the Table 1.

Table 1: LTE AS and NAS security associations

There is no requirement for data protection for a user plane tunneled between the
eNB and S-GW above network transport layer.
Therefore, extra security measures and solutions are required and needed to be taken to prevent communicated
data from disclosure of information, corruption and modification. According to ITU-T X.800 and ITU-T X.805 the
five basic security threats over an LTE network can be listed as follows:






Destruction of information and/or other resources
Corruption or modification of information
Theft, removal, or loss of information and/or other resources
Disclosure of information
Interruption of services

Figure 1 shows the LTE system architecture and security threats.

Figure 1: LTE system architecture and security threats

According to the Figure 1, the interfaces that are susceptible to security threats are the wireless plane (Uu
interface), the transport plane (S1, X2, OM channel, and Clock channel), the eNodeB equipment plane, and the
OM plane.

3

Security Solution

3.1 Huawei LTE Security Solution Architecture
Huawei LTE security strategy is to keep security breaches as local as possible.
The security architecture is in accordance with ITU-T Recommendation X.805, and consists of the following three
parts: security threats, security dimensions and security system as shown in Figure 2.

Figure 2: eNodeB security architecture

The security threats are risky factors that possibly exist in the system or affect the security in normal operation of
the system. The security dimensions are sets of security measures designed to protect system; the security
systems are objects to be protected by the security dimensions. In this white paper, the security system refers to
the eNodeB.

3.2 Huawei LTE Security Solution Highlight
3.2.1 Complete Security Solution
Huawei LTE security solution provides operator with a complete security solution that gives series of security
dimensions dealing with different security threats over the entire network. As shown in Table 2, the complete
security solution includes wireless plane, transport plane, eNodeB equipment plane, and OM plane security
solutions. The Table 2 shows the relevant planes of the eNodeB and the corresponding security solutions.
Security system

Security Solution

Wireless plane

Integrity Protection and Encryption

Transport plane

PKI, IPSec, 802.1x

eNodeB equipment Plane

Integrated firewall function,
physical security, and so on.

OM plane

User Authentication and access
control, Log and alarms, SSL, NTP
security authentication, digital
signature of software, and secure
storage.
Table 2: security system and security solution

3.2.2 Whole-process Certificate Management
Huawei whole-process digital certificate management is a PKI-based end-to-end digital certificate management
scheme that provides operator with automatic eNodeB secure deployment, and certificate based transport
security mechanisms. It is implemented in two phases: factory phase and operation phase.

3.2.3 Certificate-Based Transport Security Mechanism
Huawei transport security features such as IPSec, access control based on 802.1x, and SSL are based on digital
certificate authentication.

3.2.4 eNodeB Automatic Secure Deployment
Huawei eNodeB supports automatic secure deployment (PnP).
After powered on, the eNodeB will automatically search for the relevant security information including the
certificates first, automatically authenticate itself and establish an IPSec tunnel with the security gateway. The
whole process of the eNodeB automatic secure deployment is described in the section 5.3

3.2.5 Comprehensive Security Audit Solution

By querying logs, operator has access to a complete secure audit solution through which, it can check the security
status and security related information of the system, such as the running status, system security situation, and
user operations on M2000 or eNodeB.

3.2.6 IPSec tunnel Backup
To enhance the security reliability, Huawei eNodeB can be connected to two security gateways through one
primary IPSec tunnel, and one secondary IPSec tunnel used as backup.

3.2.7 Support of IPSec and ACL for IPv6 Environment
Huawei eNodeB supports IPSec encryption and authentication on the selected data flows with ACL under IPv6.

4

Wireless Security

Wireless security ensures the security of the data transmitted or exchanged over the Uu interface (the interface
between an eNodeB and the UE).
Integrity protection and encryption are performed on Uu interface to prevent the communication data from
information disclosure, modification and corruption. Integrity protection is performed before encryption and only
applies to the data on control plane, where as encryption applies to both control plane and data plane.
In this section of the white paper, the security keys generation, the initial security activation, and the security
mechanism activation during a handover will also be described. As part of wireless plane security, the user
authentication between the UE and the core network, will not be covered in this white paper, since it belongs to
the core network.

4.1 Integrity Protection
Integrity protection is used to prevent unauthorized modification of data on Control Plane (CP). It is performed on
the PDCP layer, as shown in Figure 3, and applies only to the Control Plane. Note that integrity is not defined for
the User Plane (UP) by 3GPP, since packet loss is tolerable on UP, and integrity protection application could add
some overhead to the transmitted data.
Integrity protection consists of integrity protection performed by the sending end and integrity verification by the
receiving end. The Integrity protection algorithm is configured by RRC signaling, and the eNodeB and UE must
support the 128-EIA1 and 128-EIA2 algorithms according to 3GPP TS 33.401 (reference document 3GPP TS
33.401). 128-EIA3, defined in R11 is optional and refers to ZUC algorithm.
The sending end uses the negotiated integrity protection algorithm to compute a MAC-I for an RRC signaling
message based on the input parameters, including KEY, BEARER, DIRECTION, COUNT (Hyper-Frame Number
(HFN) and PDU’s PDCP SN). The MAC-I is attached to the RRC signaling and sent as a part of the PDCP PDU.
After receiving the RRC signaling, the receiving end inputs the same integrity protection parameters as the
sending end, and then generates the X-MAC through the integrity protection algorithm. The receiving end
compares the X-MAC with the MAC-I attached to the RRC signaling (or PDCP SDU for the Relay enodeB). If the
X-MAC and the MAC-I are the same, the integrity verification is successful. If the X-MAC and MAC-I are different,
the data is modified and the integrity verification is not successful.
The eNodeB supports four integrity protection algorithms:
 Null algorithm: indicates that integrity protection is not applied.
 AES based algorithm
 SNOW 3G based algorithm
 ZUC: Zu Chongzhi algorithm (eRAN6.0): indicate that ZUC integrity protection is used.
The priorities of the eNodeB integrity algorithms are operator configurable. AES and SNOW3G feature the same
integrity performance. ZUC has the lowest priority.

Error: Reference source not found
Figure 3: Integrity Protection

4.2 Encryption
The encryption procedure consists of ciphering and deciphering, and it is performed on the PDCP layer, as shown
in Figure 4 for both CP and UP data.
On CP, the integrity protection is firstly performed, and then, the CP data and MAC-I are ciphered. On UP plane,
only the PDCP Service Data Unit (SDU) is ciphered. Moreover, no encryption, but only integrity protection is
performed on the RRC signaling that is used for activating the security mode. The eNodeB and UE must support
the EEA0, 128-EEA1, and 128-EEA2 algorithms according to 3GPP TS 33.401 (reference document 3GPP TS
33.401). 128-EEA3, defined in R11 is optional and refers to ZUC algorithm.

Figure 4: Encryption

When the encryption function is enabled, the eNodeB ciphers downlink data and deciphers uplink data. RRC
configures the encryption algorithm and key for all the wireless bearers such as SRB (Signaling Radio Bearer)
and DRB (Data RB). The sending end inputs the encryption parameters, including Key, Count, Bearer, Direction,
and Length. The Keystream is generated through the EPS Encryption Algorithm (EEA). Then, the sending end
performs the Exclusive-OR operation on the Plaintext and Keystream to generate the Cipher text. The receiving
end inputs the same encryption parameters as the sending end. The same Key stream is generated through the
EEA. Then, the receiving end performs the Exclusive-OR operation on the Cipher text and Key stream to
generate the Plaintext. The eNodeB supports four encryption algorithms:





Null algorithm
AES based algorithm
SNOW 3G based algorithm
ZUC: Zu Chongzhi algorithm (eRAN6.0)

The priorities of the eNodeB ciphering algorithms are operator configurable and can be set on the eNodeB. AES
and SNOW3G feature the same encryption performance. ZUC has the lowest priority.

4.3 Keys Generation

Keys are important input for the procedures of encryption and integrity protection, since to encrypt or decrypt the
data. Encryption and integrity protection have three keys: a key for integrity protection of RRC signaling, a key for
encryption of RRC signaling, and a key for encryption of UP data. To guarantee correct ciphering and deciphering,
and verification of the data integrity; the keys on the UE side and eNodeB side should be consistent. In addition,
to ensure the safety of the keys, they are derived by the UE and the eNodeB separately instead of being sent over
the Uu interface. The key derivation scheme is shown in Figure 5.

Figure 5: key derivation scheme for encryption and integrity protection









KeNodeB is used for generating KRRC int, KRRC enc, KUP enc. It is derived by the UE and MME separately from the
top-layer key of the E-UTRAN when an initial connection is set up.
KRRC int is the key used to protect the integrity of RRC signaling. It is derived by the UE and eNodeB from
KeNodeB.
KRRC enc is the key used to encrypt the RRC signaling. It is derived by the UE and eNodeB from KeNodeB.
KUP enc is the key used to encrypt the UP data. It is derived by the UE and eNodeB from KeNodeB.
KeNodeB* is generated during a handover. It is derived by UE and source eNodeB from KeNodeB, or from the
new NH, target physical cell number, and DL EARFCN (E-UTRA Absolute Radio Frequency Channel
Number). After a handover, KeNodeB* is used by the UE and target eNodeB as a new KeNodeB.
NH (Next Hop) is used by the UE and eNodeB to derive KeNodeB*. When a security context is setup, the NH
is derived by the UE and MME from KeNodeB. During a handover, the NH is derived from the previous NH.
NCC (Next Hop Chaining Count) counts the number of times that the NH is generated. During a handover,
the NCC is used to synchronize the key chain between the UE and the eNodeB. In this way, it can help to
determine whether the next KeNodeB* is derived from current KeNodeB or the new NH.

A generated key can change during handovers or during RRC Re-connection, whereas encryption and integrity
protection algorithms can only change during handovers.

4.4 Initial Security Activation Procedure
The security mode is activated when an RRC connection is being set up (after the set up of SRB1 and before the
set up of SRB2 and DRB) to enable the encryption and integrity protection. However, integrity protection and
encryption are not performed on data when the UE initiates an emergency call, and consequently, Null algorithms
are used. The process of security activation is shown in the below Figure 6.

Figure 6: initial security activation procedure

When an RRC connection is being set:
 The MME generates KeNodeB and NH, and sends KeNodeB together with UE security capability to the eNodeB.
UE security capability includes the supported encryption and integrity algorithms.
 The eNodeB generates KUP enc, KRRC int, KRRC enc based on KeNodeB and the selected security algorithms. It
configures the corresponding encryption parameters and integrity parameters for the PDCP layer.
 The eNodeB sends a Security Mode Command message, which contains the security mode parameters,
to the UE through SRB1.
 If a security complete message is received from the UE, the security activation is successful; otherwise the
security activation fails.
 After activation, the integrity protection and encryption functions are activated. Then, the eNodeB performs
integrity protection and then encryption on the CP data, whereas it performs only encryption on the UP
data.

4.5 Security Activation Procedure during a Handover

During a handover, the security related parameters are sent from the source eNodeB to the target eNodeB. Figure
7 shows the security activation process during a handover through X2 interface. Note that the process is the same
as a handover through S1 interface.

Figure 7: security activation procedure during a handover through X2
















The source eNodeB generates KeNodeB* based on NH or KeNodeB, target physical cell number, and DL
EARFCN (Downlink E-UTRA Absolute Radio Frequency Channel Number), and sent it to the target
eNodeB through X2 interface together with the UE security context that includes the UE security capability,
NCC, and KeNodeB*.
Whether to use NH or KeNodeB to generate KeNodeB* depends on whether or not the NH on the source eNodeB
is used. If the NH is used, KeNodeB is used to generate KeNodeB*. If NH is not used, then it is used to generate
KeNodeB*
The target eNodeB, after receiving the handover request message that contains the security context, will
choose the most appropriate encryption and integrity protection algorithms from its configured priority list
of encryption and integrity algorithms based on UE security capability. The target eNodeB uses the
transferred KeNodeB* as the KeNodeB, derives the keys for integrity and encryption of the RRC signaling and
key for encryption of UP data, and configures PDCP (Packet Data Control Protocol) with security
parameter that will be generated after handover.
The target eNodeB sends to the souce eNodeB the Handover Request Acknowledgement message, which
contains the NCC of the source eNodeB and the selected security algorithms.
The source eNodeB sends to the UE the RRC Connection Reconfiguration message, which contains the
NCC and security algorithms provided by the target eNodeB. The security parameters obtained before the
handover are only used for the integrity protection and encryption of the RRC Connection Reconfiguration
message sent in this procedure.
The UE uses its own KeNodeB and received NCC to generate KeNodeB*. And according to its supported security
algorithm and KeNodeB*, the UE derives the integrity key and encryption key of RRC signaling and the
encryption key of UP data. The derived keys are used on the UE side. According to its selected encryption
and integrity protection algorithm, the UE configures the PDCP with the security parameters that will be
generated after the handover.
When the UE has performed the handover successfully, it sends the RRC Connection Reconfiguration
Complete message to the target eNodeB. The security parameters that are obtained after handover are
used for the integrity protection and encryption of the RRC Connection Reconfiguration Complete
message.
The target eNodeB uses the security parameters that are obtained after handover to perform integrity
protection and encryption on the RRC signaling and UP data.
The target eNodeB sends the Path Switch Request message to inform the MME of the handover
completion.
Upon receiving the Path Switch Request message, the MME adds 1 to the NCC and generates the new
NH based on the original NH.





The MME sends the Path Switch Request Acknowledgement message to the target eNodeB. The
message contains the new NCC and NH.
The target eNodeB saves the new NCC and NH, which could be used in the next handover.
The target eNodeB sends the UE Context Release message to the source eNodeB to order the source
eNodeB to release the UE context

If the target eNodeB does not receive the Path Switch Request Acknowledge message, the NCC and NH of the
target eNodeB are not updated, and therefore the target eNodeB can only use KeNodeB to generate KeNodeB* in the
next handover.

5

Transport Security

To protect and ensure the security of the network equipments and the transport network, transport security
solutions based on Public Key Infrastructure are implemented in the eNodeB. The solutions include wholeprocess certificate management scheme, certificate-based transport mechanism, and certificate-based intelligent
eNodeB secure deployment scheme as shown in the Figure 8.
The whole-process certificate management scheme provides PKI certificate management mechanism according
to the customer requirements and Huawei delivery capacity. The certificate-based transport mechanism and
certificate-based intelligent PnP process are applications based on the whole-process certificate management
scheme.
Public Key infrastructure (PKI) is a mechanism that provides information security services. It is based on the
asymmetrical key algorithm, and serves as the foundation and core for establishing the network security system.
Compared to the user name and symmetric encryption, the PKI certificate mechanism provides an infrastructure
for secure and standardized key management. The core of the PKI mechanism lies in the management of digital
certificate (public key), including the issue, distribution, update, and cancellation of the certificate. Huawei
certificates are compliant with ITU-T X509 standards.
.

Figure 8: Huawei transport security architecture

5.1 Whole-Process Certificate Management
To support certificate-based transport security mechanism, Huawei provides the whole-process certificate
management solution, which is implemented in two phases: factory phase and operation phase.



Factory phase: the factory CA issues factory equipment certificates. The certificate preset in the eNodeB
includes equipment certificate and Huawei root certificate. The root certificate, and Certificate Revocation
List (CRL) are issued on the security information dedicated website.
Operation phase: operations in this phase involve eNodeB installation, automatic secure eNodeB
deployment using the intelligent PnP process, and automatic eNodeB certificate management based on
the whole-process certificate management scheme.

5.1.1 Basic Concepts of PKI
The core of the PKI mechanism lies in the certificate. The PKI mechanism involves the NEs that use the
certificate, PKI server (CA and CRL server) for certificate management, and certificate management between the
NE and the PKI server.

Figure 9: basic concept of Public key Infrastructure

1. Network Element (NE)
They are three types of files that are used in the network elements: the equipment certificate, the root certificate,
and the CRL.




Equipment certificate: indicates the identity of the NE and the validity of the equipment during
authentication. The Equipment certificate of the eNodeB is stored in the main control board and bound
with its ESN (Electronic serial Number). Each equipment certificate corresponds to a unique hardware,
and each main control board is preset with an equipment certificate before delivery to ensure the validity of
the Huawei eNodeB.
Root certificate: indicates the equipment certificate of the CA. It is used to verify the validity of the
equipment certificate issued by the CA. For example, the security gateway (SeGW) uses the root
certificate to verify the eNodeB.

Figure 10: certificate verification using the preset root certificate

CRL: a certificate must be revoked before it expires when any one of the following situations occurs:
 The equipment location changes
 The private key corresponding to the certificate is disclosed or enhanced.
 The equipment is stolen or discarded.
CRL records the revoked certificates. After obtaining the CRL, the NE checks the validity of the
certificates, and according to operator strategy, determines whether to trigger the related alarms or
disconnect itself.

2. PKI System
PKI server is a certificate management device, including CA and CRL server.


Certificate Authority (CA): supports certificate management, such as the issue, update, and revocation of
certificates. The operations comply with the Certificate Management Protocol version 2 (CMPv2). Huawei
provides both direct NE-CA interaction and indirect NE-CA interaction as shown in the Figure 11.

Figure 11: NE and CA supported interaction methods



Direct NE-CA interaction: The eNodeB interacts with the CA directly using CMPv2. The direct NE-CA
interaction is recommended for networking.

Indirect NE-CA interaction: The M2000 acts as an agent. CA and M2000 uses CMP interface, and
eNodeB and M2000 uses Huawei-defined interfaces.
Huawei recommend to use the Direct NE-CA interaction for certificate mangement.




CRL server: maintains the CRL. The NE obtains the CRL through the LADP or FTP periodically.

3. Certificate Management
The certificate management involves operations including certificates application, update, and revocation.




Certificate application: the NE generates and sends certificate application file to the CA. The CA issues
an equipment certificate to the NE according to the application file.
Certificate update: a certificate has a lifetime, and it must be replaced before its expiration.
Certificate revocation: A certificate must be revoked before it expires when any one of the following
situations occurs: the equipment location changes, the private key corresponding to the certificate is
disclosed or enhanced, the equipment is stolen or discarded. A revoked certificate is published on the CRL
server.

Certificate management on the eNodeB can be implemented manually or using CMPv2. The CMPv2 is
recommended to facilitate the management.

5.1.2 Certificate Management Solutions
Figure 12 shows the two phases of certificate management, which are the factory phase and the operation phase.
In the factory phase, the eNodeB is preset with a unique equipment certificate. CRL, and root certificate of factory
CA are issued on the Web portal server. In the operation phase, the operator obtains CRL, and root certificate of
factory CA from the Web portal and check them against the certificate preset by the factory to verify the validity of
the eNodeB.

Figure 12: the two phases of certificate management

1. Factory phase

A CA server is set up in Huawei factory to issue a unique certificate for each main control board. The CN domain
and Subjectaltname are configured as ESN.huawei.com, that is, the electronic serial number of the main control
board. At the same time, the root certificate of factory CA, and CRL are issued on the Web portal server.
The factory phase involves the following two steps.
1. The factory CA issues an equipment certificate to each main control board. Both the equipment certificate
and root certificate are preset in the main control board.
2. CRL, and root certificate of factory CA are issued on the Web portal server.

2. Operation phase
When an eNodeB is deployed onsite and the PnP deployment process is completed, the operator certificate
needs to be loaded for normal running. This phase involves steps 4, 5, 6, and 7.
3. The operator obtains the root certificate, and CRL from the Web portal server, preset the CRL, and root
certificate issued by the factory CA in the operator's PKI server (CA).
4. Install the board preset with the certificate.
5. Enable PnP process on the eNodeB. After authenticating the eNodeB (by checking factory equipment
certificate preset on the eNodeB against the root certificate of factory CA), the CA issues the operator's
equipment certificate and stores the operator's equipment certificate and operator's root certificate in the
eNodeB.
6. Set up IPSec tunnel between the eNodeB and the SeGW using the operator's equipment certificate.
Routine certificate management between the eNodeB and the operator CA complies with the CMPv2.

5.2 Certificate-based Transport Security Mechanism
The transport mechanism consists of IEEE 802.1x (EAP-TLS), and IPSec mechanisms. Access control based on
IEEE 802.1x ensures the valid access of the eNodeB to the transport network. Whereas, IPSec is used to provide
the security mechanism that ensures the confidentiality, integrity, and availability of data transmission. The IEEE
802.1x and IPSec provide transport security protection for different layers. Therefore, can be used separately or
together.

5.2.1 Access Control Based on IEEE 802.1x
Access Control based on IEEE 802.1x refers to the Port-Based Network Access Control protocol. It is a standard
LAN access control protocol in the IEEE 802 protocol family.
With Access Control based on IEEE 802.1 x, the MAC address of eNodeB is authenticated, and the eNodeB that
fails to the authentication are prohibited from accessing the Local Area Network (LAN) ensuring the transport
network security.
Access Control based on IEEE 802.1x performs authentication through three components, which are the
authentication client, authentication access equipment, and authentication server as shown in the Figure 13.

Figure 13: Principle of access control based on IEEE 802.1x

During the initial access, an eNodeB initiates the authentication and send the EAPoL (Extensible Authentication
Protocol over LAN) packets, which contains the information about its certificate, to the authentication access
equipment (LAN switch or other equipments). The LAN switch forwards the EAPoL packets to the RADIUS server,
which authenticates the eNodeB according to the preset Huawei root certificate.

Before authentication, only the EAPoL packets can pass through the LAN Switch; other types of data can pass
through the authorized ports when the eNodeB passes the authentication. In this way, unauthorized access is
prohibited and the transport network security is ensured.

5.2.2 IPSec
To adapt to the all-IP based transmission mode of the LTE system, the eNodeB uses IPSec to provide the security
mechanism and ensures the confidentiality, integrity, and availability of data transmission. IPSec services are the
security services provided at the IP layer, and therefore can be used by the upper-layer protocols such as the
TCP, UDP, ICMP, and SCTP. In Huawei eNodeB, IPSec is applied to S1, X2, OM and clock channels depending of
operator’s requirements.
IPSec is a collection of protocol frameworks to guarantee IP-based transmission security, providing high quality,
interoperable, and cryptology-based security for IP packets transmission. Encryption and integrity verification are
implemented on the IP layer between specific communication parties to guarantee the following security features
of packet transmission:





Data confidentiality: encryption protection is implemented on user data, which is transmitted in cipher
text.
Data integrity: the received data is authenticated to check whether the data is modified.
Authentication: the data source is authenticated to guarantee that data is transmitted from an
authenticated sender.
Anti-replay-packet: the attack by malicious users who repeatedly transmit the captured packets is
prevented. The receiving end does not accept those old or repeated packets.

1. IPSec Networking
The Figure 14 shows the typical LTE IPSec networking.

Figure 14: LTE IPSec networking scenarios

Three main factors, which are the security zone, the data flow to be protected, and the configuration mode need
to be considered in the IPSec networking.




Security zone: the operator's network can be divided into secure zone and non-secure zone. The IPSec
provides protection for the non-secure zone only. Generally, the access network is considered non-secure
while the core network is thought to be secure. The main reason lies in the fact that the equipments of the
core network are often protected by physical facilities, such as the equipment room.
Data flow to be protected: data flows requiring protection are identified and protection strategies are
formulated. Data flows requiring protection on the eNodeB include S1 interface, X2 interface, OAM
interface, and clock interface. The protection flow consists of two types:




Data flow across the secure zone: includes S1 interface, OAM interface, and clock interface. NEs to
which these interfaces belong are located in both the secure zone and the non-secure zone. For
example, the eNodeB and MME/S-GW related to the S1 interface are located in the non-secure zone
and the secure zone respectively. A SeGW needs to be configured in front of the secure zone and
IPSec is used for security protection between the eNodeB and the SeGW to protect data in the nonsecure zone.
Data flow in the non-secure zone: The X2 interfaces that are the interfaces used between among
the eNodeBs are located in the non-secure zone. Therefore, the eNodeBs and SeGW can be

configured in either concentrated mode or distributed mode. However, Huawei recommends to use
the concentrated mode networking.

Figure 15: IPSec deployment modes

In the distributed mode, a direct IPSec tunnel protection is available between every two eNodeBs. The
concentrated networking enables IPSec protection between the eNodeB and the SeGW, and it is
shared between the eNodeB and other eNodeBs.
From the above Figure 15, we can see that distributed networking requires more IPSec paths than
concentrated networking, therefore having higher management cost. For example, distributed
networking has much more sophisticated initial configurations and configuration adjustment than
concentrated networking. In addition, in actual applications, active and standby SeGWs are generally
deployed to improve the reliability of the entire network.

2. Configuration mode
The IPSec configuration consists of IPSec profile and IKE profile. In reference to the configuration profile and
operation application stated in the 3GPP TS33.210, the following configurations are recommended.




IPSec profile:


Protocol type: ESP



Encapsulation mode: tunnel mode



Encryption algorithm: 3DES and AES (128)



Integrity algorithm: SHA-I

IKE profile:


Version: IKEv2 (recommended)



Encryption algorithm: 3DES and AES (128)



Integrity algorithm: HMAC-SHA1-96



DH algorithm: DH2 (1024) and DH14 (2048)



Authentication mode: PKI and pre-shared key

Note: PKI is recommended, since, actually, the operator prefers the PKI authentication.
For detailed configuration information, please refer to the related section in Huawei Security Feature Parameters
Description.

3. IPSec Tunnel Backup
Generally, an eNodeB can be connected only to one SeGW through one IPSec tunnel. If this tunnel is faulty, data
streams cannot be transmitted in this tunnel. If IPSec tunnel backup is used, the eNodeB can be connected to two
SeGWs through one primary IPSec tunnel and one secondary IPSec tunnel. This enhances reliability of data
transmission.
Both IPSec tunnels can be available. For uplink transmission, the eNodeB uses the primary IPSec tunnel. During
downlink transmission, the eNodeB can receive data transmitted in both tunnels. In this situation, if the status of
the two tunnels is both active and functional, data can be transmitted in either tunnel from a SeGW to the
eNodeB.
The eNodeB uses BFD sessions to detect connectivity between the eNodeB and the SeGWs. If the primary IPSec
tunnel is faulty, the eNodeB switches uplink data transmission to the secondary IPSec tunnel. The SeGW can also

switch downlink data transmission to the secondary IPSec tunnel. Even after the primary tunnel resumes, the
eNodeB still uses the secondary tunnel for data transmission. The eNodeB uses the primary tunnel only after the
secondary tunnel becomes faulty.
This feature needs also to be supported by security gateway.

4. IPSec for IPv6 Transmission
eNodeBs support IPSec for IPv6 transmission. IPSec configuration principles and methods for IPv6 transmission
are similar to those for IPv4 transmission. The difference is just that IPSec for IPv6 transmission uses another set
of MOs for configuration management.

5.3 Certificate-Based eNodeB Deployment in Secure Network
Solutions
Huawei provides the certificate-based secure eNodeB deployment solution to enable the PnP function and reduce
the deployment cost in a secure networking scenario. A secure networking scenario refers to a network that is
deployed with certificate-based transport security mechanisms, such as the IEEE 802.1x, IPSec, and SSL.
The white paper describes only the auto-discovery procedure during eNodeB deployment. Other commissioning
procedures are not explained, since security mechanisms do not have any impact on them.
Security mechanisms such as SSL or SSL+IPSec for OM transmission have an impact on the eNodeB
deployment method, process, and transport network requirements. The next sections describe the eNodeB
deployment by PnP according to whether SSL only or SSL + IPSec is used for OM channel security.

5.3.1 eNodeB Deployment by PnP with SSL+IPSec for OM Transmission
1. Auto-discovery With a Public DHCP Server Deployed
The eNodeB needs to perform two DHCP procedures. During the first DHCP procedure, the eNodeB exchanges
messages with the public DHCP server. For this purpose, the public DHCP server must be configured with an
address pool and a next-hop gateway address. In addition, option 43 in a DHCP response sent to the eNodeB
must contain information about the SeGW, CA, and M2000 DHCP server, as described in Table 3. During the
second DHCP procedure, M2000 DHCP server sends OM channel information to the eNodeB. The OM channel
information is generated by M2000 when M2000 creates an eNodeB deployment task. Figure 16: auto-discovery
with a public DHCP serverFigure 16 shows the auto discovery procedure with a public DHCP server.
Subcode

Meaning

Description

18

SeGW IP
address

IP address of the SeGW (the IKE peer) with
which the eNodeB negotiates a temporary
IPSec tunnel for the second DHCP procedure

42

IP address of
the M2000
DHCP server

Configured only when unicast is used in the
second DHCP procedure

35

CA IP address

IP address of the CA from which the eNodeB
initially requests an operator-issued device
certificate

36

CA port number

Number of the CA port to which the eNodeB
sends the first certificate request

37

CA path

CA path, for example, /exampleCA/

38

CA name

CA name, which must be the same as the
subject name of the CA certificate

39

CA protocol

0: HTTP
1: HTTPS

Table 3: information to be configured in DHCP option 43 on a public DHCP server

Figure 16: auto-discovery with a public DHCP server

The procedure is as follows:
1. After starting up, the eNodeB automatically starts physical link detection, during which the eNodeB
negotiates with the peer and activates an Ethernet port for communication.
2. After the physical link is activated, the eNodeB sends a request for IEEE 802.1x-based authentication.
3. If the authentication procedure successes, the eNodeB performs VLAN acquisition, and DHCP procedure
through which it acquires a temporary port IP address, SeGW information, CA information, and M2000
DHCP server information.
4. The eNodeB applies for an operator-issued device certificate using CMP.
5. The eNodeB sets up a temporary IPSec tunnel to the SeGW.
6. Through this tunnel, the eNodeB sends a DHCP request to the M2000 DHCP server and acquires OM
channel information.
7. Based on the OM channel information, the eNodeB uses a port IP address to set up an IPSec tunnel for
OM transmission through negotiation.
8. The eNodeB sets up an SSL-based OM channel to the M2000.

2. Auto-discovery Without a Public DHCP Server Deployed
If DHCP messages from an eNodeB travel to the M2000 DHCP server without IPSec protection, no public DHCP
server is required. Figure 17 shows the auto-discovery procedure without a public DHCP server deployed.

Figure 17: auto-discovery without a public DHCP server deployed

The procedure is as follows:

1. After starting up, the eNodeB automatically starts physical link detection, during which the eNodeB
negotiates with the peer and activates an Ethernet port for communication.
2. After the physical link is activated, the eNodeB sends a request for IEEE 802.1X-based authentication.
3. If the authentication procedure is successful or expires, the eNodeB performs VLAN acquisition and a
DHCP procedure. The M2000 DHCP server responds to the eNodeB with OM channel, SeGW, and CA
information.
4. The eNodeB applies for an operator-issued device certificate using CMP.
5. Based on the acquired information, the eNodeB configures a port IP address, routes, and VLANs and sets
up an IPSec tunnel for OM transmission through negotiation.
6. The eNodeB sets up an SSL-based OM channel to the M2000.
This procedure is only supported by eRAN6.0 and above versions.

5.3.2 eNodeB Deployment by PnP with SSL only for OM channel
If SSL only is used for OM transmission, and authentication is based on operator certificates during autodiscovery, the eNodeB acquires OM channel and operator's CA information from the M2000 DHCP server through
the DHCP procedure. Then the eNodeB automatically applies for an operator-issued device certificate, as shown
in Figure 18.

Figure 18: auto-discovery with SSL and an operator-issued device certificate

The procedure is as follows:
1. After starting up, the eNodeB automatically starts physical link detection, during which the eNodeB
negotiates with the peer and activates an Ethernet port for communication.
2. After the physical link is activated, the eNodeB sends a request for IEEE 802.1X-based authentication.
3. If the authentication procedure is successful or expires, the eNodeB performs VLAN acquisition and a
DHCP procedure. The M2000 DHCP server responds to the eNodeB with OM channel and CA
information.
4. The eNodeB applies for an operator-issued device certificate using CMP.
5. Based on the acquired information, the eNodeB configures a port IP address, routes, VLANs, and an OM
channel. Then, the eNodeB sets up an SSL-based OM channel to the M2000.

6

eNodeB Equipment and OM Security

The eNodeB equipment and OM security ensures the security for the eNodeB equipment and OM plane.

Figure 19: eNodeB equipment and OM security architecture

6.1 Equipment Security
Equipment security protects the eNodeB in terms of physical security, Integrated firewall function, and secure
environment.

Figure 20: Huawei equipment security architecture

The Figure 20 shows positions of the three functions of the equipment security. The physical security ensures the
security of the hardware and eNodeB site. The integrated firewall function ensures the security of the input on the
eNodeB, and focus on anti-attack. The secure environment provides internal security protection to the eNodeB.

1 Physical Security
Currently, physical security is ensured by adding lock to the equipment room and outdoor eNodeBs. For the
indoor eNodeB, the users can lock the equipment room or use the door control system. For the outdoor eNodeB,
the user can lock the cabinet.

2 Integrated Firewall Function
The eNodeB provides the integrated firewall function, including ACL (Access List Control) packet filtering and
interface security management.

1. ACL Packet Filtering
Packets are filtered through ACL to avoid DoS attacks. During a DoS attack, the attacker sends a large number of
packets to make the eNodeB out of service. In addition to packet filtering function, ACL is also used for IPSec
matching, in which ACL is used to determine whether packets use the IPSec mechanism or not. Operator can
specify the purposes of ACL.
The eNodeB defines the ACL rules to allow or prohibit the packets that match the rules. ACL defines sextuple
rules and handling methods for packets. The sextuple rules refer to protocol type, destination IP address, source
IP address, destination port, source port, and DSCP. If a packet matches one of the ACL rules, it can be permitted
or denied.
ACL is used in two ways: white list and black list.



White list: set an ACL rule to prohibit receiving of all packets and then configuring packets to be permitted
for each data flow.
Black list: configure an ACL rule for prohibiting packets for each data flow. The operator does not need to
configure an ACL rule of receiving all packets because the default system configuration allows receiving all
packets.

From the perspective of security protection, the white list provides protection that is more comprehensive. In
addition, for the SON X2 self-setup function, an ACL rule corresponding to the X2 interface is automatically added
by the system.
From eRAN3.0, Huawei eNodeB supports ACL by layer 2 filtering. Working under L2, ACL rule will filter packets
by VLAN identification. The eNodeB identifies the VLAN ID of the packets, and only packets with own VLAN ID
will be allowed.
Huawei eNodeB supports IPSec encryption and authentication for selected data flows with ACL under IPv6.

2. Interface Security Management
Interface security management consists of communication matrix management, disabling of service Ethernet port
and commissioning Ethernet port.




Communication matrix management: the communication matrix file lists external protocol ports (TCP/UDP)
of the eNodeB and it is issued together with the product document. Communication matrix management is
the foundation of port management.
Service Ethernet port disabling: when there is no service configured on a service Ethernet port, the
operator can disable the port to avoid possible attacks.
Commissioning Ethernet port disabling: the operator can disable the commissioning Ethernet port.

3 Secure Environment
eNodeB keys can be encrypted and backed up to enhance system security. For example, a private key in the
public key infrastructure (PKI) system can be stored in encryption mode, and the key is automatically backed up
by the eNodeB. The backup private key will be used if the original private key is damaged.

2 OM Security
OM security supports four functions: user authentication and access control, log and security alarm, OM channel
security, and OM system security.

Figure 21: Huawei OM security architecture

The Figure 21 shows the positions of the four OM security functions in the system. The log and security alarm
function monitors the security of the whole system and reports the security information to the management
system. The user authentication and access control function controls the user access to avoid access of invalid
users. The OM system security protects the software and configuration data running on the eNodeB to prevent
invalid control over the eNodeB. The OM channel security ensures security for the channel between EMS
equipment and the NEs.

1 User Authentication and Access Control
The objects of user authentication and access control are the users who access the eNodeB. User authentication
is to identify and authorize the users; whereas, access control is to specify and restrict the operations to be
performed and the resources to be accessed by users.
Authentication and access control involve the following functions:

1. User Account Management
Local user account management refers to the management on adding, modifying, enabling/disabling, deletion,
and querying of local user accounts. Local user account information includes user name, user description,
operating level/access policy, permitted access time range, locking threshold for password errors, and passport
expiration management.

2. User Rights Management
A perfect authorization management mechanism supports authorization based on command level. User groups
with different authorities can be defined. Operation users in the system can be classified into different user groups
and each user belongs to a user group. All the operation commands are also classified based on command
groups. Each user must be specified with one or more authorized command group.
The system has five default user groups: Guests, Users, Operators, Administrators, and Custom (depending on
the eNodeB).


Guests: users in this user group can only view data



Users: besides the right of Guests, the system maintenance is allowed



Operators: besides the right of users, the data configuration is allowed



Administrators: besides the right of Operators, the user management (excluding the admin
management) is allowed



Custom: The operator can define a user group as required.

3. User Login Management
The eNodeB supports logins by local users, M2000 domain users, and machine-machine authentication during
EMS access. For the logins, the communication with the system is unavailable before successful authentication,
and a login prompt is displayed, indicating the last successful login. In addition, the login time can be controlled
and specified for each account.

4. User Operation Authentication
The operator cannot perform all system operations before successful login.

2 Log and Alarms
1. Logs

Operator is provided with logs that record the system history information. The history information is the most
important non-repudiation information. The system provides the following security-related logs:
 Operation logs
List the history operations that are performed by users or the system, for example, the execution of MML
commands and performance measurement initiated by the system periodically.
 Running logs
List the key information during the system operation, for example, faults and alarms.
 Security logs
List the security-related operations, such as login and logout operations performed by users.

2. Alarms
Some alarms are provided for the system security issues. Actually, the main security alarms include:
 802.1 X authentication failed alarm
 Certificate will soon expire alarm
 Peer Certificate expiry alarm
 Certificate invalid alarm
 Digital certificate automatically updated failure alarm
 Local User Consecutive Login Retries Failed alarm

3 OM Channel Security
1. Security Socket Layer
The Security Socket Layer (SSL) is a protocol that provides end-to-end communication security between TCP
layer and the application layer. It is designed to meet basic security requirements such as confidentiality, integrity,
and identification of entities. eNodeBs support the following SSL/TLS versions: SSL3.0, TLS1.0, TLS1.1, and
TLS1.2. It uses the certificates to perform the automatic encryption key management.
SSL usage is described as follows:
 SSL applies to communication between the eNodeB and the M2000.
 File Transfer Protocol over SSL (FTPS) applies to communication between the eNodeB and an FTP
server.
 HTTPS, which is also over SSL, applies to communication between the eNodeB and the LMT
An OM channel can use SSL and IPSec at the transport layer and network layer respectively to ensure channel
security. Alternatively, an OM channel can also use only SSL at the transport layer to ensure channel security.
The authentication mode depends on the operator's requirements for network security and network conditions.
Particularly, if the DCN (Data Communication) where the M2000 is located is directly connected to an un-trusted
domain in the transport network, the SSL encryption mode is recommended for OM transmission.

2. NTP Security Authentication
The eNodeB is deployed on the public network, therefore, if an invalid time source is used, its time becomes
incorrect and this will cause errors in related information such as alarms and logs, thus, affecting the maintenance
of the eNodeB.
NTP (Network Time Protocol) security authentication is used to encrypt and authenticate the NTP packets so that
the validity of the reference time received by the eNodeB is ensured. NTP security authentication supports two
encryption algorithms, that is, DES encryption and MD5 encryption. Figure 22 shows the principle of NTP security
authentication.

Figure 22: Principle of NTP security authentication

Before sending NTP packets to the eNodeB, the NTP server checks the configured NTP authentication mode to
determine whether to encrypt the NTP packets. If NTP packets are transmitted in plaintext, the NTP packets do
not need to be encrypted. If the DES or MD5 encryption algorithm is selected, the checksum of the NTP packets
is calculated through the selected algorithm, and the checksum and NTP packets are sent to the eNodeB.

4 OM System Security
1. Digital Signature of Software
The digital signature is used to ensure software integrity and reliability in the whole process from release to use.
When Huawei releases software, the digital signature is put on the software package, and the information about
the digital signature is released with the software package. After the software package is downloaded, the
eNodeB authenticates the digital signature of the software package before using it. If the authentication is
successful, the software is complete and reliable and therefore can be used. If the authentication fails, the
software package is invalid and cannot be used. Figure 23 shows the principle of the digital signature of software.

Figure 23: principle of the digital signature




Before a software package is released, a digital signature is put on all files in the software package. The
message digest of all files in the software package is calculated, and the private key is used to put a
signature on the message digest. The signature is the digital signature of the software package.
When the software package with a digital signature is loaded to M2000 or eNodeB through the software
release platform, M2000, LMT, or USB storage device, M2000 or eNodeB authenticates the digital
signature of the software package. The public key is used to decrypt the digital signature to obtain the
original message digest. In addition, a new message digest is obtained through calculation. The original
and new message digests are compared with each other.

If the two message digests are consistent, the authentication is successful, and the software can be installed or
be used for upgrade. Otherwise, the authentication will fail, and the software can not be installed or use for
upgrade.

2. Secured USB Storage Device
An eNodeB can be deployed using a USB storage device. However, software and configuration files disclosed
from the USB storage device expose the network to security risks. Therefore, software and configuration files from
the USB storage device should be encrypted and data integrity should be ensured. This type of USB storage
device is called a secured USB storage device.
Before delivery, encryption and integrity protection are implemented in a secured USB storage device. When a
secured USB storage device is inserted into the commissioning port on the eNodeB for site deployment, a
deciphering key and an integrity verification key are generated according to the random number in the secured
USB storage device and information about the eNodeB. Integrity verification is also performed before deciphering.
The secured USB storage device uses the following encryption algorithms: 3DES, AES192, and AES256. The
integrity protection algorithms are SHA256, HMAC_SHA1, and HMAC_SHA256.

3. Data Backup and Restore
eNodeB and M2000 data backup ensures data consistency and integrity. If eNodeB or M2000 data is detected as
damaged, for example, when operating systems are corrupted, backup data can be used to restore the system.

eNodeB and M2000 data can be backed up manually or automatically. One backup file is generated on the
M2000 server each time a backup task is performed, regardless of the backup mode. eNodeB data can be
restored based on these backup files.

5 OM Security Evaluation
OM security can be evaluated based on logs. Logs about eNodeBs and the M2000 are classified into operation
logs, system logs, and security logs. By querying logs, users can obtain information about the running status,
system security situation, and user operations of the M2000 or eNodeB. Users can also save logs as files or print
them out.
Users can audit the security logs collected by M2000 to evaluate OM security. The auditable security events
include:
 System startup and shutdown
 User login success and failure events: including user names, login time, workstation information (such as
IP addresses), and causes for login failures (such as incorrect passwords and invalid accounts)
 User logout success and failure events: including user names, logout time, workstation information (such
as IP addresses), and causes for logout
 Users' attempt to access resources beyond their permission
 All OM and configuration events: including user names, OM time, workstation information (such as IP
addresses), operations, and responses
 Operations concerning user accounts and permission levels: including addition, deletion, and modification

7

Conclusion

From air interface to the OM system, including the equipment, transport interfaces, and OM and clock channels,
this white paper describes and touches every aspect of LTE security solution. Huawei LTE security solution
includes wireless security solution, transport security solution, eNodeB equipment security solution, and OM
system security solution. They are complete, mature, and designed to satisfy operator’s network requirements.
Based on high professionalism, and better consulting capability and understanding of LTE network requirements,
Huawei will provide operators with the best security solutions that satisfy the most their LTE network and business
requirements while helping them keep on leading the industry.

8

Acronyms and Abbreviations

3GPP

Third Generation Partnership Project

ACL
AES
AH

Access control List
Advanced Encryption Standard
Authentication Header

CA
CMP
CP
CRL

Certificate Authority
Certificate Management Protocol
Control Plane
Certificate Revocation List

DES
DH
DHCP
DL EARFCN
DMZ
DOS
DPD
DSCP
DRB

Data Encryption Standard
Diffie-Hellman
Dynamic Host configuration Protocol
E-UTRA Absolute Radio Frequency Channel
Number
DeMilitarized Zone
Denial Of Service
Deep Packet Detection
Differentiated Service Check Point
Data Radio Bearer

EAPoL
EEA
EIA
EPS
ESN
ESP

Extensible Authentication Protocol over LAN
EPS Encryption Algorithm
EPS Integrity Algorithm
Evolved Packet System
Electronic Serial Number
Encapsulation Security Protocol

FTP

File Transfer Protocol

GTP

GPRS Tunneling Protocol

HMAC

Hash-based Message Authentication Code

IKE
IKE SA
IP
IPSec
IPSec SA
ISAKMP

Internet Key Exchange
IKE Security Association
Internet Protocol
Internet Protocol Security
IPSec Security Association
Internet Security Association and Key
management Protocol
International Telecommunication Union Telecommunication

ITU-T
LAN
LDAP
LMT

Local Area Network
Lightweight Directory Access Protocol
Local Maintenance Terminal

MAC-I
MD5
MML

Message Authentication Code I
Message Digest algorithm 5
Machine Man Language

NCC
NH

Next hop Chaining Count
Next Hop

NTP

Network Time Protocol

OM

Operation and Management

PDCP
PDU
PKI
PnP
PRF

Packet Data Control Protocol
Protocol Data Unit
Public Key Infrastructure
Plug and Play
Pseudo Random Function

RA
RADIUS
RRC

Registration Authority
Remote Authentication Dial-in User Server
Radio Resource Control

SDU
SeGW
SHA
SPI
SRB
SSL
SCTP

Service Data Unit
Security Gateway
Secure Hash Algorithm
Security Parameter Index
Signaling Radio Bearer
Security Socket Layer
Stream Control Transport Protocol

TCP
TLS

Transport Control Protocol
Transport Layer Security

UDP
ULP
UP
USB

User Datagram Protocol
Upper Layer Protocol
User Plane
Universal Serial Bus

VLAN

Virtual Local Area Network

WLAN

Wireless Local Area Network

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close