IPsec(SRAN8.0_02)

SingleRAN

IPsec Feature Parameter Description

Issue 02Date 2013-07-30

HUAWEI TECHNOLOGIES CO., LTD.

Copyright Huawei Technologies Co., Ltd. 2013. All rights reserved.No part of this document may be reproduced or transmitted in any form or by any means without prior writtenconsent 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. NoticeThe purchased products, services and features are stipulated by the contract made between Huawei and thecustomer. All or part of the products, services and features described in this document may not be within thepurchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information,and recommendations in this document are provided "AS IS" without warranties, guarantees or representationsof any kind, either express or implied.

The information in this document is subject to change without notice. Every effort has been made in thepreparation of this document to ensure accuracy of the contents, but all statements, information, andrecommendations in this document do not constitute a warranty of any kind, express or implied. Huawei Technologies Co., Ltd.Address: Huawei Industrial Base

Bantian, LonggangShenzhen 518129People's Republic of China

Website: http://www.huawei.comEmail: [email protected]

Issue 02 (2013-07-30) Huawei Proprietary and ConfidentialCopyright Huawei Technologies Co., Ltd.

i

Contents

1 About This Document..................................................................................................................11.1 Scope..............................................................................................................................................................................11.2 Intended Audience..........................................................................................................................................................21.3 Change History...............................................................................................................................................................22 Overview.........................................................................................................................................53 IPsec Working Principles.............................................................................................................73.1 Security Association.......................................................................................................................................................73.2 IPsec Policies..................................................................................................................................................................83.3 IPsec Proposal.................................................................................................................................................................93.3.1 Security Protocols........................................................................................................................................................93.3.2 Encapsulation Modes.................................................................................................................................................103.3.3 Encryption and Verification Algorithms...................................................................................................................133.4 IPsec Service Procedure...............................................................................................................................................144 IKE Working Principles.............................................................................................................154.1 Introduction..................................................................................................................................................................154.2 IKE Negotiation............................................................................................................................................................164.2.1 IKEv1 Negotiation.....................................................................................................................................................164.2.2 IKEv2 Negotiation.....................................................................................................................................................174.2.3 Key Generated by IKE Negotiation...........................................................................................................................184.3 IKE Proposal.................................................................................................................................................................184.3.1 Introduction...............................................................................................................................................................184.3.2 Encryption and Verification Algorithms...................................................................................................................184.3.3 Authentication Method..............................................................................................................................................184.3.4 DH Group and PRF Algorithm..................................................................................................................................194.3.5 IKE SA Lifetime........................................................................................................................................................194.4 IKE Security Mechanism..............................................................................................................................................204.5 IKE DPD.......................................................................................................................................................................205 IPsec Reliability...........................................................................................................................215.1 IPsec Tunnel Backup....................................................................................................................................................226 IEEE 1588v2 over IPsec...............................................................................................................23

SingleRANIPsec Feature Parameter Description Contents


ii

7 IPsec Application.........................................................................................................................257.1 Typical IPsec Networking............................................................................................................................................257.2 Application of IPsec on Macro Base Stations..............................................................................................................267.2.1 Application of IPsec on GBTSs.................................................................................................................................267.2.2 Application of IPsec on eGBTSs, NodeBs, and eNodeBs........................................................................................287.2.3 Application of IPsec on Multimode Base Stations....................................................................................................287.3 External IPsec on the Base Station Controller Side.....................................................................................................297.4 Application of IPsec on Cascaded Base Stations.........................................................................................................307.5 Network Evolution Solutions.......................................................................................................................................318 Related Features...........................................................................................................................338.1 Features Related to Integrated IPsec on the Base Station.............................................................................................348.2 Features Related to IPsec Tunnel Backup....................................................................................................................349 Network Impact...........................................................................................................................3610 Engineering Guidelines...........................................................................................................3910.1 When to Use IPsec......................................................................................................................................................3910.2 Required Information.................................................................................................................................................3910.3 Planning......................................................................................................................................................................4110.3.1 Network Planning....................................................................................................................................................4110.3.2 Hardware Planning..................................................................................................................................................4310.4 Requirements..............................................................................................................................................................4410.5 Configuration Principles.............................................................................................................................................4510.5.1 IPsec Policies...........................................................................................................................................................4510.5.2 ACL Rules...............................................................................................................................................................4610.6 Deployment of IPsec on a PKI-based Secure Network..............................................................................................4710.6.1 Deploying IPsec on an eGBTS, NodeB, or eNodeB...............................................................................................4710.6.2 Deploying IPsec on a GBTS (GTMUb+UMPT_L)................................................................................................6910.6.3 Deploying IPsec on a GBTS (GTMUb+UTRPc)....................................................................................................7110.6.4 Deploying Co-IPsec on a GL Dual-Mode Base Station (UMPT_GL/GTMUb+UMPT_L)...................................9310.6.5 Deploying Co-IPsec on a GU Dual-Mode Base Station (UMPT_GU/GTMUb+UMPT_U)..................................9610.6.6 Deploying Co-IPsec on a UL Dual-Mode Base Station (UMPT_UL/UMPT_U+UMPT_L).................................9910.6.7 Deploying Co-IPsec on a GUL Multimode Base Station (UMPT_GUL).............................................................10210.6.8 Deploying Co-IPsec on a GUL Multimode Base Station (UMPT_L+GTMUb+UCIU in the Root BBU and UMPT_Uin the Leaf BBU)..............................................................................................................................................................10410.6.9 Deploying Co-IPsec on a GUL Multimode Base Station (UMPT_U+GTMUb+UCIU in the Root BBU and UMPT_Lin the Leaf BBU)..............................................................................................................................................................10610.7 Deployment of IPsec on a PSK-based Secure Network...........................................................................................10810.7.1 Data Preparation....................................................................................................................................................10910.7.2 Initial Configuration..............................................................................................................................................11110.7.3 Activation Observation..........................................................................................................................................11110.8 Secure Configuration Modification on a Reconstructed Network...........................................................................11210.8.1 Reconstruction from an Insecure Network to a PKI-based Secure Network........................................................112



iii

10.8.2 Reconstruction from an Insecure Network to a PSK-based Secure Network.......................................................11710.8.3 Reconstruction from a PSK-based Secure Network to a PKI-based Secure Network..........................................12210.9 Performance Monitoring...........................................................................................................................................12510.10 Performance Optimization......................................................................................................................................12510.11 Troubleshooting......................................................................................................................................................12511 Parameters.................................................................................................................................12612 Counters....................................................................................................................................20313 Glossary.....................................................................................................................................20714 Reference Documents.............................................................................................................208



iv

1 About This Document1.1 Scope

This document describes the Internet Protocol Security (IPsec) , including its technicalprinciples, related features, network impact, and engineering guidelines.This document covers the following features:l GBFD-113524 BTS Integrated IPsecl WRFD-140209 NodeB Integrated IPSecl LOFD-003009 IPsecl MRFD-211602 Co-IPSec Between GSM, UMTS and LTE (GSM)l MRFD-221602 Co-IPSec Between GSM, UMTS and LTE (UMTS)l MRFD-231602 Co-IPSec Between GSM, UMTS and LTE (LTE)Any managed objects (MOs), parameters, alarms, or counters described herein correspond tothe software release delivered with this document. Any future updates will be described in theproduct documentation delivered with future software releases.Table 1-1 lists the definitions of all kinds of macro base stations.

Table 1-1 Definitions of all kinds of base stationsBase StationName

Definition

GBTS GBTS refers to a base station deployed with GTMU.eGBTS eGBTS refers to a base station deployed with UMPT_G.NodeB NodeB refers to a base station deployed with WMPT or UMPT_U.eNodeB eNodeB refers to a base station deployed with LMPT or UMPT_L.

SingleRANIPsec Feature Parameter Description 1 About This Document


1

Base StationName

Definition

Co-MPTMultimode BaseStation

Co-MPT multimode base station refers to a base station deployed withUMPT_GU, UMPT_GL, UMPT_UL, or UMPT_GUL, and itfunctionally corresponds to any combination of eGBTS, NodeB, andeNodeB. For example, Co-MPT multimode base station deployed withUMPT_GU functionally corresponds to the combination of eGBTSand NodeB.

Separate-MPTMultimode BaseStation

Separate-MPT multimode base station refers to a base station on whichdifferent modes use different main control boards. For example, basestations deployed with GTMU and WMPT are called separate-MPTGSM/UMTS dual-mode base station.

1.2 Intended AudienceThis document is intended for personnel who:l Need to understand the features described hereinl Work with Huawei products

1.3 Change HistoryThis section provides information about the changes in different document versions. There aretwo types of changes, which are defined as follows:l Feature change

Changes in features of a specific product versionl Editorial change

Changes in wording or addition of information that was not described in the earlier version

02 (2013-07-30)This issue includes the following changes.

Change Type Change Description ParameterChange

Feature change None NoneEditorial change Deleted the descriptions of IPsec supported by micro

base stations.None

01 (2013-04-28)This issue does not include any changes.



2

Draft B (2013-04-10)This issue includes the following changes.

Change Type Change Description ParameterChange

Feature change Implemented IPsec on micro base stations. NoneEditorial change None None

Draft A (2012-12-30)This document is created for SRAN8.0.As to GSM BSS/WCDMA RAN, the name of the document is changed into IPsec FeatureParameter Description from Transmission Security Feature Parameter Description.As to eRAN, this document is derived from Transmission Security Feature ParameterDescription.Compared with Issue 02 (2012-07-20) of SRAN7.0, Draft A (2012-12-30) of SRAN8.0 includesthe following changes.

Change Type Change Description Parameter ChangeFeature change Added IPsec deployment scenarios for

eGBTSs.None

Added the IEEE 1588v2 over IPsecsolution. For details, see chapter 6 IEEE1588v2 over IPsec.

None

Editorial change Added descriptions of the IPsec securityassociation (SA) and anti-replay window.For details, see chapter 3 IPsec WorkingPrinciples.

None

Revised descriptions of IKEv1negotiation. For details, see section 4.2.1IKEv1 Negotiation.

None

Added descriptions of the Diffie-Hellman(DH) group and pseudo-random function(PRF) algorithm. For details, see section4.3.4 DH Group and PRF Algorithm.

None

Simplified the base station deploymentprocess in typical scenarios. For details,see section 7.1 Typical IPsecNetworking.

None



3

Change Type Change Description Parameter ChangeModified the application of IPsec on basestations. For details, see section 7.2Application of IPsec on Macro BaseStations.

None

Modified the description of IPsec-relatedfeatures. For details, see chapter 8Related Features.

None

Revised IPsec engineering guidelines, anddetailed how to deploy IPsec on GBTSs,eGBTSs, NodeBs, eNodeBs, andmultimode base stations in differentnetworking scenarios. For details, seechapter 10 Engineering Guidelines.

None



4

2 OverviewThe evolution from radio networks to IP-based networks has improved network performanceand reduced network deployment costs. However, inherent vulnerabilities on IP networks leavethem open to security threats.Before IPsec is introduced, a base station transmits control-plane data, user-plane data, andmanagement-plane data in plaintext. Packets transmitted on an insecure network are vulnerableto unauthorized access or malicious modification. To ensure secure data transmission, Huaweibase stations incorporate the IPsec function, by which IPsec tunnels are established.As defined by the Internet Engineering Task Force (IETF), IPsec is a security mechanismimplemented at the IP layer and consists of three protocols: Authentication Header (AH),Encapsulation Security Protocol (ESP), and IKE. IPsec provides transparent end-to-end securityservices for IP networks, thereby protecting the networks from cyber attacks.With IPsec, two communicating peers (also known as IPsec peers) ensure the following securityfeatures of IP packets transmitted on the network by encrypting the packets and authenticatingthe data source:l Confidentiality: An IPsec entity encrypts user data and transmits the data in ciphertext to

prevent the data from being disclosed on the transmission path. The IPsec entity is thenetwork element (NE) or network equipment that uses IPsec for communication.

l Integrity: The IPsec entity checks the received data to ensure that it has not been tamperedwith.

l Authenticity: The IPsec entity authenticates the data source.l Anti-replay protection: The IPsec entity identifies and rejects packets that are intercepted

and repeatedly sent by malicious users.IPsec tunnels between the base station and security gateway (SeGW) can protect datatransmission between the base station and base station controller. Figure 2-1 shows a securenetwork.

SingleRANIPsec Feature Parameter Description 2 Overview


5

Figure 2-1 Secure network

SingleRANIPsec Feature Parameter Description 2 Overview


6

3 IPsec Working Principles3.1 Security Association

Before using IPsec tunnels for secure data transmission, an SA must be established betweencommunicating peers. An SA defines security policies negotiated between communicating peersto protect data flows. The security policies involve:l Security protocolsl Encapsulation modesl Verification algorithmsl Encryption algorithmsl Key for data protection and key lifetimeThere are two types of SAs in the IPsec framework: IPsec SAs and IKE SAs. IPsec SAs areestablished by negotiation under the protection of IKE SAs. IKE SAs are established bynegotiation between IKE peers. An IKE SA defines the IKE SA lifetime and encryption,verification, authentication, and Pseudo-random Function(PRF) algorithms used between IKEpeers. For details, see section 4 IKE Working Principles.IPsec SAs are unidirectional, and therefore at least two IPsec SAs are required to protect dataflows in two directions. Figure 3-1 shows an example of an IPsec SA.

SingleRANIPsec Feature Parameter Description 3 IPsec Working Principles


7

Figure 3-1 Example of an IPsec SA

NOTE

The Security Parameter Index(SPI) is used to identify IPsec SAs. Each IPsec SA has a unique SPI.

Each IPsec SA uses either AH or ESP to provide security services. If both AH and ESP are used,each IPsec entity requires two IPsec SAs: one for AH and the other for ESP.An IPsec SA has a limited lifetime. After the lifetime elapses, the IPsec SA becomes invalid.Before an IPsec SA becomes invalid, IKE establishes a new IPsec SA by negotiation. For detailsabout the IPsec SA, see IETF RFC 4301.

3.2 IPsec PoliciesSecurity services offered by IPsec are based on IPsec policies defined by a Security PolicyDatabase (SPD). The SPD specifies which security services are to be offered to IP packets andprovides information about how to obtain these services.The SPGN and SPSN parameters specify an IPsec policy. An IPsec policy includes thefollowing:l Access control list (ACL)

An ACL consists of a series of ACL rules, which specify the data flows to be protected.Only data flows that comply with ACL rules can enter an IPsec tunnel.

l IPsec proposalAn IPsec proposal defines how to protect data flows, that is, which protocol type,encapsulation mode, and encryption and verification algorithms are used. For details, seesection 3 IPsec Working Principles.

l IKEIKE is used to specify the identity authentication method and the encryption, verification,and key generation algorithms before an ISPec SA is established. For details, see chapter4 IKE Working Principles.



8

l IPsec SA lifetimeThe LTCFG, LTS, and LTKB parameters specify the IPsec SA lifetime. If LTCFG is setto GLOBAL, the IPsec SA lifetime is set to 3600 seconds. If LTCFG is set to LOCAL, theIPsec SA lifetime is configured by LTS and LTKB. If LTKB is set to 0, traffic-based IPsecSA validity judgment is disabled. An IPsec SA becomes invalid when its lifetime reachesthe value of LTS or LTKB.

l Anti-replay windowThe REPLAYWND parameter specifies the anti-replay window size.If this parameter is set to WND_DISABLE(0), the window size is 0 and therefore the anti-replay function is disabled.If this parameter is set to WND_32(32), WND_64(64), WND_128(128), WND_256(256), WND_512(512), WND_1024(1024), WND_2048(2048), or WND_4096(4096),the window size is 32, 64, 128, 256, 512, 1024, 2048, or 4096, respectively. Base stationscheck for packet duplicates within the window. If a packet has a duplicate within thewindow or falls on the left of the window, base stations discard the packet.It is recommended that the anti-replay function be disabled if there is a severe out-of-orderproblem in IPsec packets on live networks. For example, such a problem could occur whendifferentiated services code point (DSCP) values are attached to IPsec packets based onservice types due to scheduling at network nodes. If the anti-replay function is enabled inthis situation, a large number of IPsec packets may be lost, which severely affects serviceperformance.

Base stations can negotiate one or multiple IPsec SAs based on a set of parameters related toIPsec policies. The number of negotiated IPsec SAs depends on the number of configured ACLrules. If the ACTION parameter in an ACLRULE MO is set to PERMIT, one incoming IPsecSA and one outgoing IPsec SA can be negotiated for the corresponding ACL rule.

3.3 IPsec ProposalAn IPsec proposal covers security protocols, encapsulation modes, and encryption andverification algorithms.

3.3.1 Security ProtocolsIPsec uses two security protocols: AH and ESP, which are described in Table 3-1 .

Table 3-1 AH and ESPSecurityProtocol

Function Verification Scope ApplicationScenario

AH l Integrity protectionl Anti-replay

AH verifies both the IPpacket header andpayload.

Non-confidentialdata

ESP l Integrity protectionl Anti-replayl Encryption

ESP verifies only the IPpayload.

Confidential data



9

AH and ESP can be applied separately or jointly. When both are used, ESP takes precedenceover AH.IPsec tunnels protect IP packets by encapsulating the packets. Both AH and ESP support twopacket encapsulation modes: transport mode and tunnel mode. The transport mode applies tothe host's packets, whereas the tunnel mode applies to packets transmitted on forwardingequipment. For details about the packet encapsulation modes, see section 3.3.2 EncapsulationModes.Data integrity protection or encryption provided by AH or ESP relies on the verification andencryption algorithms. For details, see section 3.3.3 Encryption and VerificationAlgorithms .Protocol types, encapsulation modes, and encryption and verification algorithms are negotiatedbetween the base station and SeGW. In addition, the key used in data encryption is generatedbased on IKE negotiation. For details about IKE, see chapter 4 IKE Working Principles.For details about AH, see IETF RFC 4302. For details about ESP, see IETF RFC 4303.

3.3.2 Encapsulation ModesIPsec supports two packet encapsulation modes: transport mode and tunnel mode.

Transport ModeIn transport mode, an AH header is inserted after the IP header of the original packet and beforeany other transport layer protocol, as shown in Figure 3-2.

Figure 3-2 AH packet encapsulation format used in transport mode

In transport mode, an ESP header is inserted after the IP header of the original packet and beforeany other transport layer protocol, and an ESP trailer and an ESP authenticator are attached tothe rear of the original packet, as shown in Figure 3-3.

Figure 3-3 ESP packet encapsulation format used in transport mode



10

In transport mode, the source IP address for packets sent by a base station is the service oroperation and maintenance (O&M) IP address of the base station, and the destination IP addressfor the packets is the service or O&M IP address of peer equipment.Generally, IP packets transmitted between hosts are encapsulated in transport mode. The sendingequipment encrypts IP packets and the receiving equipment decrypt the IP packets. The transportmode is used only for end-to-end IPsec protection.Figure 3-4 shows the end-to-end protocol stack in transport mode.

Figure 3-4 End-to-end protocol stack in transport mode

Tunnel ModeIn tunnel mode, an AH header is prefixed to the IP header of the original packet, and a new IPheader is prefixed to the AH header. Figure 3-5 shows the format used for encapsulating AHpackets in tunnel mode.

Figure 3-5 AH packet encapsulation format used in tunnel mode

In tunnel mode, an ESP header is prefixed to the IP header of the original packet, and a new IPheader is prefixed to the ESP header. Figure 3-6 shows the format used for encapsulating ESPpackets in tunnel mode.



11

Figure 3-6 ESP packet encapsulation format used in tunnel mode

AH does not provide integrity protection for some variable fields in an IP packet, such as Typeof Service, Time to Live, and Checksum. This is because these fields may be legally modifiedduring transmission.In tunnel mode, IPsec encrypts an IP header of the original packet and generates a new IP header,which is used for route forwarding. The new IP header always uses the interface IP address ofa base station and the IP address of the peer equipment (usually, an SeGW) as the source anddestination IP addresses, respectively. The IP header of the original packet contains the serviceor O&M IP address of the base station.Figure 3-7 shows the end-to-end protocol stack in tunnel mode.

Figure 3-7 End-to-end protocol stack in tunnel mode

If the sending equipment does not encrypt the packets or the receiving equipment does notdecrypt the packets, IPsec peers usually use the tunnel mode for communication. Figure 3-7shows an example of using the tunnel mode between a base station and a SeGW.

Figure 3-8 Tunnel mode example



12

SummaryThe transport and tunnel modes differ in the following ways:l Security: The tunnel mode provides higher security than the transport mode, because the

entire original IP packet is encrypted and integrity protection is performed in tunnel mode.l Performance: The transport mode provides better transmission performance than the tunnel

mode, because a new IP header is added in tunnel mode and therefore more bandwidth isused.

In addition, in tunnel mode, an SeGW must be deployed on a network to separate the securityand non-security domains. The SeGW must also support functions, such as encapsulation intunnel mode, encryption, and integrity protection. In transport mode, both communicating peersmust support functions, such as IKE negotiation, encryption, and integrity protection. Therefore,users must comprehensively consider security, deployment, and performance when choosingbetween the two encapsulation modes. The chosen encapsulation mode must be supported bythe IPsec peer.The ENCAPMODE parameter specifies the encapsulation mode.

3.3.3 Encryption and Verification AlgorithmsEncryption Algorithm

ESP encrypts IP packets to prevent unauthorized access during packet transmission. Theencryption algorithm uses symmetric keys so that the same key is used by IPsec peers forencryption and decryption. Base stations support the following encryption algorithms:l Data Encryption Standard (DES)l Triple Data Encryption Standard (3DES)l Advanced Encryption Standard 128 (AES128)l AES192l AES256Compared with DES and 3DES, AES is more secure and provides higher encryption speed.3DES is more secure than DES, but 3DES takes longer to encrypt than DES. Therefore, DES isnot recommended for security reasons.

Verification AlgorithmBoth AH and ESP can check the integrity of IP packets to determine whether the IP packetswere tampered with during transmission. The verification algorithm is implemented mainlybased on a hash function, which accepts messages of any length and generates outputs of a fixedlength. The outputs are called message digests. Upon receiving a packet from the IPsec localend, the IPsec peer calculates the digests and compares them with those carried in the packet. Ifthe two sets of digests are the same, the packet is complete and has not been tampered with. Basestations support the following verification algorithms:l Message digest algorithm 5 (MD5)l Secure hash algorithm 1 (SHA-1)



13

l SHA-256l AES-XCBC (extension-cipher-block-chaining)-MAC-96Among the four verification algorithms, MD5 has the lowest security level and therefore is notrecommended.For details about MD5, see IETF RFC 2403. For details about SHA, see IETF RFC 2404.

3.4 IPsec Service ProcedureFigure 3-9 shows the IPsec service procedure.

Figure 3-9 IPsec service procedure

The IPsec service procedure is as follows:1. IPsec peers establish an IKE SA by IKE negotiation.2. The IPsec peers establish an IPsec SA by IPsec negotiation.3. During data communication, the IPsec local end encrypts data that complies with ACL

rules, and the IPsec peer end decrypts the received data.



14

4 IKE Working Principles4.1 Introduction

IPsec SAs can be manually configured. However, due to an increase in security equipment onthe network, manual configuration is difficult and can hardly ensure security. IKE can be usedto automatically establish SAs to simplify using and managing IPsec.Currently, IPsec SAs canbe established for base stations by using IKE, not manual configuration.IKE is a security mechanism based on the Internet Security Association and Key ManagementProtocol (ISAKMP) framework. It provides encryption and authentication algorithms and keynegotiation for communicating peers. It also securely distributes keys, authenticates identities,and establishes IPsec SAs on insecure networks. The details are as follows:l IKE SA establishment

An ISAKMP SA (also known as IKE SA) is established based on IKE negotiation. TheIKE SA provides an authenticated and secure channel for data exchange. Under theprotection of the IKE SA, an IPsec SA is established by negotiation.IKE negotiation involves the IKE protocol version, negotiation mode, and IKE proposal.

l Session key generationCommunicating peers perform a Diffie-Hellman (DH) exchange to generate session keys,which are then used for IKE encryption, IKE data integrity check, IKE authentication, andIPsec data encryption. During the DH exchange, session key materials are exchanged.

l Identity authenticationCommunicating peers exchange identity information to authenticate each other. Thisinformation includes authentication methods agreed upon in IKE negotiation and keysgenerated by DH exchange.

IP addresses for the IKE local and peer ends (specified by LOCALIP and REMOTEIP,respectively) must be specified for IKE negotiation.For details about IKE, see IETF RFC 4301, IETF RFC 2409, and IETF RFC 4306.

SingleRANIPsec Feature Parameter Description 4 IKE Working Principles


15

4.2 IKE NegotiationThere are two IKE versions: IKEv1 and IKEv2. The two versions have different negotiationprocesses.

4.2.1 IKEv1 NegotiationIKEv1 defines two phases for IPsec key negotiation and IPsec SA establishment.l In the first phase, communicating peers establish an IKE SA.l In the second phase, the communicating peers negotiate and establish an IPsec SA under

the protection of the IKE SA. The IPsec SA is used for secure data transmission.A negotiation mode is an information exchange mode used during IKE negotiation. IKEv1allows for three negotiation modes: main mode, aggressive mode, and quick mode.In the first phase, either main mode or aggressive mode can be used.l If main mode is used, an IKE SA is established after three exchanges, as shown in Figure

4-1. Policy negotiation: An IKE proposal is negotiated by exchanging IKE policies. DH exchange: A shared key is generated by exchanging key materials. Identity authentication: Communicating peers exchange identity information and

authenticate each other based on the negotiated IKE proposal and generated key.l If aggressive mode is used, an IKE SA is established as follows:

The initiator sends the first message to the responder. This message contains the IKEproposal, key materials, and identity information. The responder sends the second message to the initiator. This message contains the IKE

proposal, DH exchange information, identity information, and authentication payload. The initiator sends the third message to the responder. This message contains the

authentication payload.Main mode is recommended in the first phase according to the following comparisons:l Main mode is more secure than aggressive mode because identify information is encrypted

in main mode but is not encrypted in aggressive mode.l Multiple IKE proposals can be negotiated at a time in main mode, whereas only one IKE

proposal can be negotiated at a time in aggressive mode.l Main mode provides stronger negotiation capability but more complex negotiation process

than aggressive mode.NOTE

If a pre-shared key (PSK) is used for IKE authentication, main mode can use only IP addresses for peerauthentication. In this case, the IDTYPE parameter must be set to IP.

The IKEVERSION parameter specifies the IKE version. The EXCHMODE parameter specifiesthe negotiation mode in the first phase of IKEv1 negotiation.



16

Figure 4-1 IKEv1 negotiation in main mode

In the second phase, quick mode is used. In this mode, an IPsec SA is established by exchangingthree messages.

4.2.2 IKEv2 NegotiationCompared with IKEv1, IKEv2 simplifies the exchange process. Only two exchanges are requiredto establish an IKE SA and the first IPsec SA, as shown in Figure 4-2. If more than one IPsecSA needs to be established, information exchange is required only for each corresponding IPsecSA.

Figure 4-2 IKEv2 negotiation process



17

4.2.3 Key Generated by IKE NegotiationAfter the exchange of key materials, communicating peers use these materials to generate sevenkeys, of which:l Two keys are used to encrypt subsequent messages.l Two keys are used for the integrity protection of subsequent messages.l Two keys serve as the ciphering keys for identity authentication.l One key is used for IPsec data encryption and integrity protection.

NOTE

Subsequent messages are those sent during IKE negotiation after the DH exchange.

For details about the key generation method, see section 4.3.4 DH Group and PRFAlgorithm.

4.3 IKE Proposal4.3.1 Introduction

An IKE proposal consists of the encryption algorithm, verification algorithm, authenticationmethod, DH group, PRF algorithm, and IKE SA lifetime.During IKE negotiation, the IKE local end uses its IKE proposal to negotiate with the IKE peerend and establishes an IKE SA, thereby providing security services for IPsec SA negotiation.

4.3.2 Encryption and Verification AlgorithmsHuawei base stations support the following encryption and verification algorithms:l Encryption algorithms, including:

DES 3DES AES128 AES192 AES256

l Verification algorithms, including: MD5 SHA1 AES-XCBC-MAC-96 (only IKEv2 supports)

MD5 and DES are not recommended because they have low security.

4.3.3 Authentication MethodIKE supports two methods for authenticating IPsec peers: PSK and digital certificate.l PSK



18

After encrypting a message with a PSK, the sending party sends the encrypted message tothe receiving party. The receiving party decrypts the message with the same PSK. If themessage is decrypted successfully, the authentication is successful.When PSK authentication is used, communicating peers must use the same PSK. Users canpredefine the PSK by using a Universal Serial Bus (USB) flash drive on a base station.

l Digital certificateThis method enables communicating peers to authenticate each other based on digitalcertificates. Certificates are difficult to counterfeit and are managed with a completemechanism. For example, certificates have validity periods and can be revoked. Therefore,certificates are more reliable than PSKs. A public key infrastructure (PKI) system managesdigital certificates for network equipment. For details, see PKI Feature ParameterDescription.

4.3.4 DH Group and PRF AlgorithmWhen IKE is used, both communicating peers can exchange data to calculate a session keywithout transferring any keys. Even if a third party intercepts all exchanged data, it cannotcalculate the correct key because the DH algorithm and PRF are used.A DH group determines the length of the material used for key generation. Base stations supportthe following DH groups:l DH_GROUP1: defines 768-bit materiall DH_GROUP2: defines 1024-bit materiall DH_GROUP14: defines 2048-bit materiall DH_GROUP15: defines 3072-bit materialThe material length determines the security level. A longer length indicates a higher securitylevel.PRF is a highly-reliable unidirectional function that generates keys. After the DH exchange ofkey materials, communicating peers use these materials as an input to PRF and generate a key.Base stations support the following PRF algorithms:l HMAC_MD5l HMAC_SHA1l AES128_XCBCThe DHGRP parameter specifies a DH group, and the PRFALG parameter specifies a PRFalgorithm.For details about PRF, see IETF RFC 4306.

4.3.5 IKE SA LifetimeAn IKE SA has a limited lifetime. Before the lifetime expires, another SA is automaticallyestablished to replace the old one.A long lifetime may allow the key to be cracked. A short lifetime triggers frequent IKEnegotiations, which may interrupt ongoing IPsec sessions because IKE negotiation takes timeto perform the DH exchange and calculate session keys. To prevent IKE SA updates fromaffecting secure communication, a lifetime longer than 10 minutes is recommended.



19

The DURATION parameter specifies the IKE SA lifetime.

4.4 IKE Security MechanismThe IKE security mechanism is described as follows:l DH exchange and key distribution

Before encrypting IP packets, communication peers must perform a DH exchange togenerate session keys by negotiation. IKE ensures that the communication peers exchangedata to calculate session keys without transferring any keys. Even if a third party, such asa hacker, intercepts all exchanged data, they cannot calculate the correct key.

l Perfect forward secrecy (PFS)PFS is a security feature, in which the decoding of one key does not affect the security ofother keys because no session key can be derived from any other key. PFS is guaranteedby the DH algorithm.

l Identity authenticationThe communication peers authenticate each other.

l Identity protectionTo protect identity data, it is sent in encrypted mode after a key is generated.

4.5 IKE DPDIP and IPsec are unidirectional and connectionless. When IPsec peers communicate, there is aprobability that one end may not know if the other end because of abnormalities such as a systemfailure. If this occurs, the normal end continues to transmit IPsec traffic, resulting in traffic loss.Dead peer detection (DPD) is introduced to detect the peer status (online or offline) for basestations. DPD can be enabled by setting the DPD parameter to PERIODIC.The local end starts DPD only when both of the following conditions are met:l The local end does not receive IPsec packets from the peer end within the period specified

by the DPDIDLETIME parameter.l The local end needs to send IPsec packets to the peer end.If the local end receives an acknowledgement from the peer end after sending a DPD message,it considers the peer end online or normal. If the local end does not receive any acknowledgementfrom the peer end after sending the DPD message multiple times (specified by theDPDRETRN parameter), it considers the peer end unresponsive. In this case, the local end re-initiates IKE negotiation and begins to record security events. The local end retransmits DPDmessages at an interval specified by the DPDRETRI parameter.For details about DPD, see IETF RFC 3706.



20

5 IPsec Reliabilityl IPsec Tunnel Backup

Two IPsec tunnels, one primary and one secondary, are established between a base stationand two SeGWs. If the primary IPsec tunnel becomes faulty, data flows are automaticallyswitched to the secondary IPsec tunnel. Therefore, the reliability of IPsec data transmissionis enhanced.

SingleRANIPsec Feature Parameter Description 5 IPsec Reliability


21

5.1 IPsec Tunnel BackupIf IPsec is activated, the base station can communicate with the SeGW through the primary andsecondary IPsec tunnels, which operate in hot backup mode. The base station negotiatesindividual IKE tunnels and IPsec tunnels for the primary and secondary SeGWs. This ensuresthe reliability of the IPsec tunnels. Normally, IPsec traffic is transmitted through the primaryIPsec tunnel. If the primary IPsec tunnel is faulty, for example, due to a link failure, services areautomatically switched over to the secondary IPsec tunnel. The services are not automaticallyswitched back to the primary IPsec tunnel even when the primary IPsec tunnel recovers.In the uplink, the base station usually uses the primary IPsec tunnel to send packets accordingto user configurations. The MSPGN or MSPSN parameter specifies the primary IPsec tunnel.The SSPGN or SSPSN parameter specifies the secondary IPsec tunnel. In the downlink, therouter must support the dynamic routing protocol to select routes.When primary and secondary IPsec tunnels are used, the base station must use BidirectionalForwarding Detection (BFD) to detect connectivity between the base station and the SeGW. Toenable BFD, an IPsec tunnel must be bound to a BFD session ID. If BFD detects that the primaryIPsec tunnel is faulty:l In the uplink, the base station automatically switches services to the secondary IPsec tunnel.l In the downlink, the SeGW requires that BFD be bound to the dynamic routing protocol in

order to switch services to the secondary IPsec tunnel. If the SeGW detects that the primaryIPsec tunnel is faulty, the SeGW automatically switches services to the secondary IPsectunnel.

On the base station side, the source and destination IP addresses for a BFD session must be thesame as the local and peer IP addresses for the associated primary or secondary IPsec tunnel,respectively.For details about BFD, see IP Transport Architecture Feature Parameter Description.Theapplication constraints of IPsec Tunnel Backup are as follows:l IPsec Tunnel Backup cannot be used when two SeGWs work in hot backup mode.l When the primary IPsec tunnel is recovered, uplink data flows will not be automatically

switched back to the primary IPsec tunnel, which may cause asymmetrical data flows inthe uplink and downlink. This requires that the firewall on the SeGW side supportunidirectional data flows and the SeGW can trigger IKE negotiation.

l IPsec Tunnel Backup does not apply to scenarios where the base station provides onetransmission port with VLAN configurations and one transmission port without VLANconfigurations.

l If IPsec tunnel backup is enabled and the OM channel is IPsec-encrypted,the base stationcannot be deployed in PnP mode.

SingleRANIPsec Feature Parameter Description 5 IPsec Reliability


22

6 IEEE 1588v2 over IPsecData processing at the IP and Media Access Control (MAC) layers may be delayed. To eliminatethe delay and provide accurate timestamps for clock packets, IEEE 1588v2 defines that atimestamp is attached after data processing at the MAC layer and before data processing at thephysical layer, as shown in Figure 6-1 . After an IEEE 1588v2 clock packet is encapsulated byMAC and upper-layer protocols, an NE uses equipment to detect the User Datagram Protocol(UDP) port number carried in the packet before data processing at the physical layer. If the UDPport number is 319, the NE attaches a timestamp to the packet to record the leaving or arrivaltime of the packet.

Figure 6-1 Timestamp processing in IEEE 1588v2

IPsec encrypts and verifies packets at the IP layer, whereas timestamps are attached to IEEE1588v2 clock packets between data processing at the MAC layer and data processing at thephysical layer. As a result, two problems occur when IPsec is used to provide confidentialityand data integrity protection for IEEE 1588v2 clock packets. The problems are as follows:l After IPsec encryption, the UDP port number carried in an IEEE 1588v2 clock packet

cannot be identified.l After IPsec data integrity protection by the sender, an IEEE 1588v2 clock packet fails the

data integrity check performed by the receiver due to an attached timestamp.

SingleRANIPsec Feature Parameter Description 6 IEEE 1588v2 over IPsec


23

To solve these problems, the IEEE 1588v2 over IPsec solution is introduced. This solutionenables IPsec encryption for Layer 3 (L3) unicast packets in frequency synchronization. Theprocedure is as follows:1. Upon receiving an encrypted packet that cannot be identified as an IEEE 1588v2 clock

packet, the base station records the arrival time of the packet and sends the timestamp tothe upper layer together with the encrypted packet.

2. The base station decrypts the encrypted packet and checks whether the packet is an IEEE1588v2 clock packet based on the UDP port number.

3. If the packet is an IEEE 1588v2 clock packet, the base station checks the leaving time ofthe packet. The base station then uses the Adapter Clock Recover (ACR) algorithm torestore the clock frequency based on the leaving and arrival time of the packet.

NOTE

This solution applies only to L3 unicast packets in frequency synchronization. This solution does not applyto time synchronization because time synchronization has the following restrictions:l Timestamps are required for all L3 equipment between the base station and SeGW.l Intermediate equipment cannot identify IEEE 1588v2 clock packets within encrypted packets.

SingleRANIPsec Feature Parameter Description 6 IEEE 1588v2 over IPsec


24

7 IPsec Application7.1 Typical IPsec Networking

Huawei base stations support IPsec. To protect data transmitted between the base station andbase station controller, an SeGW must be deployed on the network.In typical IPsec networking, the base station and the SeGW use digital certificates to authenticateeach other. Therefore, a PKI system and a public DHCP server must be deployed on the operator'snetwork. As stipulated in 3GPP TS 33.310, the Initialization Response message sent by theoperator's CA server must contain the operator's root certificate or certificate chain. Theoperator's CA server must be preconfigured with the Huawei root certificate.Figure 7-1 showsthe typical IPsec networking.

Figure 7-1 Typical IPsec networking

SingleRANIPsec Feature Parameter Description 7 IPsec Application


25

NOTE

The connection mode between the router and SeGW is determined in the network plan.l On an existing network, an SeGW is recommended on the router side.l On a newly deployed network, the router should connect directly to the SeGW.

In the typical IPsec networking, the base station must obtain a device certificate from the CAbefore an IPsec tunnel is established between the base station and SeGW. For details about howto apply for a device certificate, see PKI Feature Parameter Description.Base stations can be deployed in two modes in the typical IPsec networking:l Automatic base station deployment by plug and play (PnP)

If a public DHCP server is deployed on the network and O&M data is protected byIPsec, two temporary IPsec tunnels are established between the base station and SeGW.The base station uses the second IPsec tunnel to obtain the configuration file. After theconfiguration file is obtained, the base station negotiates with the SeGW according tothe file, and establishes a formal IPsec tunnel. For the purpose and requirements oftemporary IPsec tunnels, see Automatic OMCH Establishment Feature ParameterDescription. If no public DHCP server is deployed on the network and O&M data is protected by

IPsec, only one temporary IPsec tunnel is established between the base station andSeGW. The base station uses the IPsec tunnel to obtain the configuration file. After theconfiguration file is obtained, the base station negotiates with the SeGW according tothe file, and establishes a formal IPsec tunnel. For the automatic OMCH establishmentprocedure, see Automatic OMCH Establishment Feature Parameter Description. If O&M data is not protected by IPsec, the base station directly obtains the configuration

file, negotiates with the SeGW according to the file, and establishes a formal IPsectunnel.

l Automatic base station deployment by USBThe base station negotiates with the SeGW according to the configuration file and directlyestablishes a formal IPsec tunnel.

7.2 Application of IPsec on Macro Base StationsTo apply IPsec on a Huawei base station, the base station must be configured with a UMPT,LMPT, or UTRPc because only Ethernet ports on these boards support IPsec.

7.2.1 Application of IPsec on GBTSsA GBTS uses either of the following board combinations to implement IPsec:l GTMUb+UMPT_L/LMPT

The GTMUb and UMPT_L/LMPT communicate with each other through the BBUbackplane, and the UMPT_L/LMPT provides IPsec and transfers GBTS data.Figure 7-2 shows an example of implementing IPsec on a GBTS configured with theGTMUb and UMPT_L.



26

Figure 7-2 Example of implementing IPsec on a GBTS configured with the GTMUb andUMPT_L

NOTE

UMPT_L refers to a UMPT working in LTE(FDD) mode,and UMPT_T refers to a UMPT working in LTE(TDD) mode.

l GTMUb+UTRPcThe GTMUb and UTRPc communicate with each other through the BBU backplane, andthe UTRPc provides IPsec and connects to the transport network.Figure 7-3 shows an example of implementing IPsec on a GBTS configured with theGTMUb and UTRPc.

Figure 7-3 Example of implementing IPsec on a GBTS configured with the GTMUb and theUTRPc

GTMUb+UMPT_L is recommended for GBTSs to implement IPsec.The UTRPc cannot be used for existing 3012 series base stations. To implement IPsec on sucha base station or to enable the base station to support IPsec after being upgraded to a multimodebase station, an external SeGW must be deployed on the base station side, as shown in Figure7-4.

Figure 7-4 External SeGW deployed on the base station side



27

7.2.2 Application of IPsec on eGBTSs, NodeBs, and eNodeBsGenerally, an eGBTS, NodeB, or eNodeB uses a UMPT_G, UMPT_U, UMPT_L or UMPT_Tto implement IPsec, as shown in Figure 7-5 .

NOTE

UMPT_G refers to the UMPT working in GSM mode, UMPT_U refers to the UMPT working in UMTSmode, UMPT_L refers to the UMPT working in LTE(FDD) mode,and UMPT_T refers to the UMPTworking in LTE(TDD) mode.

Figure 7-5 Example of implementing IPsec on an eGBTS, NodeB, or eNodeB

To implement IPsec on an existing 3812 series base station or to enable the base station to supportIPsec after being upgraded to a multimode base station, an external SeGW must be deployed onthe base station side.

7.2.3 Application of IPsec on Multimode Base StationsMultimode base stations are classified into co-MPT and separate-MPT multimode base stations.IPsec can be applied on both of them.

Co-IPsec on Co-MPT Multimode Base StationsTo implement co-IPsec:l A co-MPT GU dual-mode base station uses a UMPT_GU.

The UMPT_GU supports GSM and UMTS and provides IPsec for eGBTS and NodeB dataflows.

l A co-MPT GL dual-mode base station uses a UMPT_GL.The UMPT_GL supports GSM and LTE and provides IPsec for eGBTS and eNodeB dataflows.

l A co-MPT UL dual-mode base station uses a UMPT_UL.The UMPT_UL supports UMTS and LTE and provides IPsec for NodeB and eNodeB dataflows.

l A co-MPT GUL multimode base station uses a UMPT_GUL, as shown in Figure 7-6.The UMPT_GUL supports GSM, UMTS, and LTE and provides IPsec for eGBTS, NodeB,and eNodeB data flows.



28

Figure 7-6 Example of implementing co-IPsec on a co-MPT GUL multimode base station

Co-IPsec on Separate-MPT Multimode Base StationsTo implement co-IPsec:l A separate-MPT GU dual-mode base station uses GTMUb+UMPT_U.

The GTMUb and UMPT_U communicate with each other through the BBU backplane,and the UMPT_U provides IPsec for GBTS and NodeB data flows.

l A separate-MPT GL dual-mode base station uses GTMUb+UMPT_L .The GTMUb and UMPT_L communicate with each other through the BBU backplane, andthe UMPT_L provides IPsec for GBTS and eNodeB data flows.

l A separate-MPT UL dual-mode base station uses UMPT_U+UMPT_L .The UMPT_U and UMPT_L or communicate with each other through the BBU backplane,and the UMPT_L provides IPsec for NodeB and eNodeB data flows.

l A separate-MPT GUL multimode base station uses UMPT_L+GTMUb+UCIU or in theroot BBU and the UMPT_U in the leaf BBU, as shown in Figure 7-7.The two BBUs are interconnected by connecting the UCIU and UMPT_U. In the root BBU,the GTMUb and UMPT_L communicate with each other through the BBU backplane, andthe UMPT_L or UMPT_T provides IPsec for GBTS, NodeB, and eNodeB data flows.

Figure 7-7 Example of networking for co-IPsec on a separate-MPT GUL multimode base station

NOTE

Implementing Co-IPsec on a separate-MPT multimode base station requires co-transmission.

7.3 External IPsec on the Base Station Controller SideIf bearer networks such as leased networks and public networks encounter security threats, IPsectunnels can be used to isolate network services for secure transmission. Currently, base station



29

controllers do not support integrated IPsec and therefore can only use external IPsec. Figure7-8 shows an example of external IPsec on the base station controller side.

Figure 7-8 Example of external IPsec on the base station controller side

The throughput of an external SeGW must exceed the planned total traffic volume on GSM andUMTS user planes.If no SeGW is deployed on the operator's network, it is recommended that you use HuaweiEudemon1000E-X or Eudemon8000E-X to implement external IPsec on the base stationcontroller side.It is recommended that the following functions be disabled on the SeGW:l Whitelist

Interface boards on a base station controller have firewalls and provide the whitelistfunction.

l Packet filtering based on the UDP port numberDisabling this function on the SeGW prevents normal packets from being filtered out.

Whether to deploy an external SeGW for IPsec depends on customer requirements.

7.4 Application of IPsec on Cascaded Base StationsWhen base stations are cascaded, IPsec can be implemented in two ways:l Each base station has a separate IPsec tunnel and the Hub base station provides route

forwarding, as shown in Figure 7-9 .l The Hub base station provides one IPsec tunnel or all cascaded base stations, as shown in

Figure 7-10 .



30

Figure 7-9 Separate IPsec tunnel for each base station and route forwarding by the Hub basestation

Figure 7-10 IPsec tunnel provided by the Hub base station for all cascaded base stations

In base station cascading scenarios, it is recommended that the Hub base station be used onlyfor route forwarding, as shown in Figure 7-9 .

7.5 Network Evolution SolutionsOperators use three evolution solutions described in Table 7-1 to reconstruct existing networks.

Table 7-1 Network evolution solutionsNetwork Evolution Solution Network Equipment Deployment

RequirementEvolution from an insecure transport network to asecure network that uses digital certificateauthentication (referred to as the PKI-basedsecure network)

A PKI system, public DHCP server, andSeGW must be deployed. The SeGW canuse digital certificates to authenticate theidentity of the peer end.



31

Network Evolution Solution Network Equipment DeploymentRequirement

Evolution from an insecure transport network to asecure network that uses PSK authentication(referred to as the PSK-based secure network)

An SeGW must be deployed. The SeGWcan use a PSK to authenticate the identityof the peer end.

Evolution from a PSK-based secure network to aPKI-based secure network

A PKI system, public DHCP server, andSeGW must be deployed. The SeGW canuse digital certificates to authenticate theidentity of the peer end.

In the evolution from an insecure transport network to a secure network, if the SeGW and PKIsystem have already been deployed, operators can directly upgrade the insecure transportnetwork to a PKI-based secure network. During the evolution, users need to download andactivate configuration data. This process interrupts ongoing services.In the evolution from a PSK-based secure network to a PKI-based secure network, users needto modify configuration data online and specify a board where a certificate is to be deployed.The base station must be reset for the modifications to take effect, which interrupts ongoingservices. Users can run the SET BTSCERTDEPLOY and SET CERTDEPLOY commandsto set a board where a certificate is to be deployed on the GBTS and the eGBTS/NodeB/eNodB,respectively.



32

8 Related FeaturesThe IPsec feature relates to the following features:l GBFD-113524 BTS Integrated IPsecl WRFD-140209 NodeB Integrated IPSecl LOFD-003009 IPsecl MRFD-211602 Co-IPSec Between GSM, UMTS and LTE (GSM)l MRFD-221602 Co-IPSec Between GSM, UMTS and LTE (UMTS)l MRFD-231602 Co-IPSec Between GSM, UMTS and LTE (LTE)l LOFD-003019 IPsec Tunnel Backup

SingleRANIPsec Feature Parameter Description 8 Related Features


33

8.1 Features Related to Integrated IPsec on the Base StationPrerequisite Features

l GBFD-113524 BTS Integrated IPsecThis feature requires the GBFD-118601 Abis over IP feature. If IPsec uses digital certificateauthentication, this feature also requires the GBFD-113526 BTS Supporting PKI feature.

l WRFD-140209 NodeB Integrated IPSecThis feature requires the WRFD-050402 IP Transmission Introduction on Iub Interfacefeature. If IPsec uses digital certificate authentication, this feature also requires theWRFD-140210 NodeB PKI Support feature.

l LOFD-003009 IPsecIf IPsec uses digital certificate authentication, this feature requires the LOFD-003010Public Key Infrastructure(PKI) feature.

l MRFD-211602 Co-IPSec Between GSM, UMTS and LTE (GSM)This feature requires the GBFD-118601 Abis over IP feature. If IPsec uses digital certificateauthentication, this feature also requires the GBFD-113526 BTS Supporting PKI feature.

l MRFD-221602 Co-IPSec Between GSM, UMTS and LTE (UMTS)This feature requires the WRFD-050402 IP Transmission Introduction on Iub Interfacefeature. If IPsec uses digital certificate authentication, this feature also requires theWRFD-140210 NodeB PKI Support feature.

l MRFD-231602 Co-IPSec Between GSM, UMTS and LTE (LTE)If IPsec uses digital certificate authentication, this feature requires the LOFD-003010Public Key Infrastructure(PKI) feature.

Mutually Exclusive FeaturesThe GBFD-113524 BTS Integrated IPsec and MRFD-211602 Co-IPSec Between GSM, UMTSand LTE (GSM) features cannot be used together with the GBFD-117702 BTS Local Switchfeature.The MRFD-211602 Co-IPSec Between GSM, UMTS and LTE (GSM) feature cannot be usedtogether with the GBFD-118611 Abis IP over E1/T1 feature.

Impacted FeaturesNone

8.2 Features Related to IPsec Tunnel BackupPrerequisite Features

The LOFD-003019 IPsec Tunnel Backup feature requires the LOFD-003009 IPsec andLOFD-003007 Bidirectional Forwarding Detection features.



34

Mutually Exclusive FeaturesNone

Impacted FeaturesNone



35

9 Network ImpactSystem Capacity

No impact.

Network PerformanceIPsec ensures transmission security by encapsulating and encrypting IP packets. This reducesthe transmission efficiency of service packets on the bearer network.Take ESP encapsulation in tunnel mode as an example. Assume that the IP payload is 500 bytes,the packet length (including the IP header and Ethernet header) before IPsec encapsulation is540 bytes, the encryption algorithm is 3DES, and the authentication algorithm is MD5. Then,the packet structure after encapsulation is as follows:20 bytes (Ethernet header) + 20 bytes (external IP header) + 8 bytes (ESP header) + 20 bytes(internal IP header) + 8 bytes (initialization vector) + 500 bytes (payload) + 2 bytes (padding)+ 2 bytes (ESP trailer) + 16 bytes (integrity check value for MD5)The total length is 596 bytes. The transmission efficiency decreases from 92.59% to 83.89%.The impact of IPsec on the transmission efficiency of service data varies depending on theprotocol, algorithm, and encapsulation mode. Table 9-1 and Table 9-2 describe the impact ofIPsec on the transmission efficiency when AH and the MD5, SHA, or SHA2 (256 bits) algorithmare used for data integrity check.

Table 9-1 Impact of IPsec on the transmission efficiency in transport modeServiceAlgorithm

FR MCS-9

AMR12.2k

PS32kbps

CS64kbps

PS128kbps

PS384kbps

IPsecdisabled

32% 65.5% 29% 51.6% 69.3% 78.6% 83.5%

MD5 25% 58.3% 22.9% 43.7% 61.8% 73.6% 79.6%SHA 24.4% 57.4% 22.3% 42.8% 60.8% 72.9% 78.9%

SingleRANIPsec Feature Parameter Description 9 Network Impact


36

ServiceAlgorithm

FR MCS-9

AMR12.2k

PS32kbps

CS64kbps

PS128kbps

PS384kbps

SHA2 22.4% 54.8% 20.5% 40.2% 58.2% 71.0% 77.5%

Table 9-2 Impact of IPsec on the transmission efficiency in tunnel modeServiceAlgorithm

FR MCS-9 AMR12.2k

PS 32kbps CS64kbps

PS128kbps

PS384kbps

IPsecdisabled

32% 65.5% 29% 51.6% 69.3% 78.6% 83.5%

MD5 21.9% 54% 20.0% 39.4% 57.4% 70.3% 77.0%SHA 21.3% 53.2% 19.4% 38.6% 56.5% 69.7% 76.6%SHA2 19.8% 51% 18.4% 36.5% 54.2% 67.9% 75.1%

Table 9-3 and Table 9-4 describe the impact of IPsec on the transmission efficiency when ESPand the DES, 3DES, or AES algorithm are used for encryption.

Table 9-3 Impact of IPsec on the transmission efficiency in transport modeServiceAlgorithm

FR MCS-9 AMR12.2k

PS32kbps

CS64kbps

PS128kbps

PS384kbps

IPsecdisabled

32% 65.5% 29% 51.6% 69.3% 78.6% 83.5%

DES/3DES+MD5

23.9% 56.4% 22.1% 43.0% 60.2% 72.4% 78.7%

DES/3DES+SHA

23.2% 55.6% 21.5% 42.1% 59.3% 71.7% 78.2%

AES+MD5

23.9% 55.6% 20.9% 41.2% 58.4% 71.1% 78.7%

AES+SHA

23.2% 54.8% 20.3% 40.4% 57.6% 70.5% 78.2%



37

Table 9-4 Impact of IPsec on the transmission efficiency in tunnel modeServiceAlgorithm

FR MCS-9 AMR12.2k

PS32kbps

CS64kbps

PS128kbps

PS384kbps

IPsecdisabled

32% 65.5% 29% 51.6% 69.3% 78.6% 83.5%

DES/3DES+MD5

20.4% 52.5% 18.7% 38.1% 56.7% 69.9% 76.7%

DES/3DES+SHA

19.9% 51.7% 18.3% 37.4% 55.9% 69.3% 76.2%

AES+MD5

19.4% 52.5% 18.7% 38.1% 55.2% 68.7% 76.7%

AES+SHA

19.4% 51.7% 18.3% 37.4% 54.4% 68.1% 76.2%

If IPsec is enabled on an operator's network, the time required for initial base station deploymentincreases by less than 2 minutes when transmission is available. The increased time, caused bycertificate requests and IPsec tunnel setups, depends on the response speed of the public DHCPserver and the encryption protocol used by the SeGW.



38

10 Engineering Guidelines10.1 When to Use IPsec

Unlike time division multiplexing (TDM) networks, IP networks cannot ensure transmissionsecurity. If an operator uses a public IP network, activate the IPsec feature to provide integrityand confidentiality protection for wireless services. If the operator requires that IPsec negotiationuse digital certificate authentication, activate the PKI feature. For details about how to activatethe PKI feature, see PKI Feature Parameter Description.

10.2 Required InformationBefore activating the IPsec feature, engineering personnel must confirm the peer SeGWconfiguration information listed in Table 10-1 with the operator to ensure successful IPsecnegotiation between communicating peers.

Table 10-1 Information for IPsec negotiationInformation to Be Collected Parameters on the Base Station

SideIKE information IKE version Version

IKEv1 exchange mode Exchange ModeType of the local ID Local ID TypeIP address of the SeGW Remote IP Address

SingleRANIPsec Feature Parameter Description 10 Engineering Guidelines


39

Information to Be Collected Parameters on the Base StationSide

IKE name of the SeGWNOTEl If a PSK is used for identity

authentication, obtain the localname of the SeGW.

l If digital certificates are usedfor identity authentication,obtain information about thesubjectaltname field in thedevice certificate used by theSeGW.

Remote Name

IKE encryption algorithm Encryption AlgorithmIKE integrity protectionalgorithm

Authentication Algorithm

IKE PRF algorithm PRF AlgorithmIKE DH group Diffie-Hellman GroupDPD switchNOTE

If DPD is enabled on the SeGW,obtain the following information:l DPD Idle Timel DPD Retransmission Intervall DPD Retransmission Count

DPD Mode

DPD idle time DPD Idle TimeDPD packet retransmissioninterval

DPD Retransmission Interval

Number of DPD packetretransmissions

DPD Retransmission Count

Authentication method Authentication MethodIPsec information IPsec encapsulation mode Encapsulation Mode

IPsec protocol type TransformESP encryption algorithm ESP Encryption AlgorithmESP integrity protectionalgorithm

ESP Authentication Algorithm

AH integrity protectionalgorithm

AH Authentication Algorithm

Perfect forward secrecy (PFS)flag

Perfect Forward Secrecy



40

10.3 Planning10.3.1 Network PlanningIPsec Networking

IPsec networking concerns three major factors:l Security and non-security domains

An operator's network is divided into security and non-security domains. IPsec protectsonly the non-security domain. Usually, the core network (CN) is considered secure and theaccess network is considered insecure. SeGWs are deployed between the two domains toprovide IPsec for data flows transmitted between the base station and SeGW.

l Authentication methodTwo authentication methods can be used between the base station and SeGW: PKI andPSK authentication. Depending on the authentication method, IPsec networks are classifiedinto PKI- and PSK-based secure networks. They have different deployment requirements.For details, see section 10.4 Requirements.

l Data flow protectionData flows on the base station include signaling, services, O&M, and clock data flows. Innetwork planning, the operator must identify data flows to be protected and specifyprotection policies. Huawei base stations provide IPsec and Secure Sockets Layer (SSL)protection for O&M data flows.

Figure 10-1 shows an example of the PKI-based secure network in which O&M data flows areprotected by IPsec and can be protected by SSL first.

Figure 10-1 Example of the PKI-based secure network in which O&M data flows are protectedby IPsec

Figure 10-2 shows an example of the PKI-based secure network in which O&M data flows areprotected by SSL rather than IPsec.



41

Figure 10-2 Example of the PKI-based secure network in which O&M data flows are protectedby SSL rather than IPsec

Centralized protection is recommended for data flows transmitted by eNodeBs over X2interfaces. In centralized protection mode, an IPsec tunnel is established between each eNodeBand the SeGW. During communication, the IPsec tunnel protects data flows transmitted overX2 interfaces.

Figure 10-3 Example of the IPsec network on the X2 interface

Networking with IPsec Tunnel BackupWhen the IPsec Tunnel Backup feature is used, a pair of primary and secondary IPsec tunnelsare established between a base station and two SeGWs. In typical networking, the base stationprovides one or two physical ports for IPsec tunnel establishment, depending on the actualtransmission conditions.l If two physical ports are provided, IPsec policies are bound to the two ports and BFD is

enabled, as shown in Figure Figure 10-4 .



42

Figure 10-4 Example of networking in which the base station provides two physical ports

l If one physical port is provided, security policies are bound to the same port and BFD isenabled, as shown in Figure 10-5 .

Figure 10-5 Example of networking in which the base station provides one physical port

10.3.2 Hardware PlanningGBTS/eGBTS

Among 3900 series GSM base stations, GBTSs must be configured with a UMPT_L, LMPT, orUTRPc to support IPsec and IPsec Tunnel Backup; eGBTSs must be configured with a UMPT_Gto support IPsec and IPsec Tunnel Backup.

NodeBTo support IPsec and IPsec Tunnel Backup, 3900 series WCDMA base stations must beconfigured with a UMPT_U or UTRPc.

eNodeB3900 series LTE base stations must be configured with a UMPT_L, LMPT, or UTRPc to supportIPsec and IPsec Tunnel Backup.

Multimode Base Station3900 series multimode base stations must be configured with a UMPT, LMPT, or UTRPc toprovide security protection.



43

10.4 RequirementsThe IPsec feature has the following deployment requirements:l An SeGW is deployed on the operator's network.l The SeGW complies with the encryption protocol defined in IETF RFC 2409 or 4306 and

supports PKI or PSK authentication.l The license for the IPsec feature has been activated.Table 10-2 lists the license information

for IPsec.

Table 10-2 License information for IPsecFeature ID Feature

NameLicenseControl Item

NE Sales Unit

GBFD-113524 BTS IntegratedIPsec

BTS IntegratedIPsec

GBTS/eGBTS

Per GBTS/eGBTS

WRFD-140209

NodeBIntegratedIPsec

NodeBIntegratedIPsec

NodeB Per NodeB

LOFD-003009 IPsec IPsec eNodeB Per eNodeBMRFD-211602

Co-IPsecBetween GSM,UMTS andLTE (GSM)

Co-IPsecBetween GSM,UMTS andLTE (GSM)

MBTS Per MBTS

MRFD-221602

Co-IPsecBetween GSM,UMTS andLTE (UMTS)

Co-IPsecBetween GSM,UMTS andLTE (UMTS)

MBTS Per MBTS

MRFD-231602

Co-IPsecBetween GSM,UMTS andLTE (LTE)

Co-IPsecBetween GSM,UMTS andLTE (LTE)

MBTS Per MBTS

NOTE

The co-IPsec license activation rules for a multimode base station are as follows:l The co-IPsec license needs to be activated only for the mode that provides a transmission port. For

example, to implement co-IPsec on a GU dual-mode base station, only the license for theMRFD-221602 Co-IPsec Between GSM, UMTS and LTE (UMTS) feature needs to be activated if atransmission port is provided by the UMTS mode.

l If a UTRPc provides a transmission port, the co-IPsec license needs to be activated for the mode thatcontrols the UTRPc. For example, if the UMTS mode controls the UTRPc, the license for theMRFD-221602 Co-IPsec Between GSM, UMTS and LTE (UMTS) feature must be activated.



44

l If digital certificate authentication is used between the base station and SeGW, the PKIdeployment requirements must also be met. For details, see PKI Feature ParameterDescription.

l If PSK authentication is used between the base station and SeGW, the same PSK must bepreconfigured on both sides.

The IPsec Tunnel Backup feature has the following deployment requirements:l Single- or multi-hop BFD sessions can be established between the base station and SeGW.l The SeGW can publish the BFD status to NEs in the security domain, enabling the NEs to

dynamically modify downlink routes.l The license for the IPsec Tunnel Backup feature has been activated. Table 10-3 lists the

license information for IPsec Tunnel Backup.

Table 10-3 License information for IPsec Tunnel BackupFeature ID Feature Name License NE Sales UnitLOFD-003019 IPsec Tunnel

BackupIPsec TunnelBackup

eNodeB Per eNodeB

l The license for the LOFD-003007 Bidirectional Forwarding Detection feature has been

activated.NOTE

GBTSs, eGBTSs, and NodeBs do not have the license for the IPsec Tunnel Backup feature.

10.5 Configuration Principles

10.5.1 IPsec PoliciesThe operator can configure one or multiple IPsec policies according to actual network conditions.Each IPsec policy is bound to one ACL. In an ACL, one or multiple ACL rules can be configuredfor data flows that need to be protected by IPsec. The base station provides IPsec for data flowsthat comply with the ACL rules. An IPsec policy takes effect only after it is bound to atransmission port.IPsec configuration principles are as follows:l An ACL rule is added to an ACL by using the ACLID parameter.l An IKE proposal is bound to an IKE peer by using the PROPID parameter.l An ACL is bound to an IPsec policy by using the ACLID parameter.l An IKE peer is bound to an IPsec policy by using the PEERNAME parameter.l An IPsec proposal is bound to an IPsec policy by using the PROPNAME parameter.l An IPsec policy is bound to a transmission port by using the SPGN parameter.Figure 10-6 shows the IPsec configuration principles.



45

Figure 10-6 IPsec configuration principles

NOTE

Each IPsec tunnel corresponds to an IPsec policy, which is specified by the SPGN and SPSN parameters.Multiple IPsec SAs can be established in an IPsec tunnel. The number of IPsec SAs depends on the numberof configured ACL rules. The operator can configure specific ACL rules for different types of data flowsto establish individual IPsec SAs for these data flows.In various network conditions, the configuration of LMPT is the same as that of UMPT_L.The IKECFG MO is optional. For PSK-based secure networks, the IKELNM parameter in the IKECFGMO must be set when the IDTYPE parameter in the IKEPEER MO is set to FQDN.

If the operator requires multiple IPsec tunnels, multiple IPsec policies must be configured andbound to different IKE peers and ACLs. If the operator requires multiple IPsec policies to bebound to the same port, these policies must have the same SPGN value but different SPSNvalues. Multiple IPsec policies can be bound to the same port by using the SPGN parameter.

10.5.2 ACL RulesACL rules are configured in two modes:l Any to Any

The value of RULEID for an ACL rule whose ACTION is set to DENY must be smallerthan that for an ACL rule whose ACTION is set to PERMIT. In Any to Any mode,configure ACL rules as follows:1. Configure an ACL rule with the parameter settings as follows:

- SIP: set to an interface IP address.- SWC and DIP: set to 0.0.0.0.- DWC: set to 255.255.255.255.- ACTION: set to DENY.

2. Configure ACL rules for data flows that do not need to be protected by IPsec.The parameter settings for the ACL rules are as follows:- SIP: set to the source IP address of the data flow.-SWC and DIP: set to 0.0.0.0.- DWC: set to 255.255.255.255.- ACTION: set to DENY.

3. Configure an ACL rule in Any to Any mode with the parameter settings as follows:



46

SIP and DIP: set to 0.0.0.0. SWCand DWC: set to 255.255.255.255. ACTION: set to PERMIT. The value of RULEID for an ACL rule whose ACTION is set to DENY must be smaller

than that for an ACL rule whose ACTION is set to PERMIT.l IP to Any

Configure ACL rules for data flows that need to be protected by IPsec.The parameter settings for the ACL rules are as follows: SIP: set to the source IP address of the data flow SWC and DIP: set to 0.0.0.0. DWC: set to 255.255.255.255. ACTION: set to PERMIT.

NOTEl Any to Any mode applies only to scenarios where a base station is interconnected with an SeGW

provided by Juniper. The following sections use IP to Any mode as an example to describe how toconfigure ACL rules. The specific method for configuring ACL rules depends on the network plan.

l No two ACL rules can apply to the same data flow.

10.6 Deployment of IPsec on a PKI-based Secure NetworkThis section describes IPsec data preparation, initial configuration, and activation observationon a PKI-based secure network. For the PKI data preparation, initial configuration, and activationobservation, see PKI Feature Parameter Description.

10.6.1 Deploying IPsec on an eGBTS, NodeB, or eNodeBOn a PKI-based secure network, IPsec configurations are the same for eGBTSs, NodeBs, andeNodeBs. This section uses the network shown in Figure 10-7 as an example to describe howto deploy IPsec on an eNodeB on a PKI-based secure network.

Figure 10-7 Example of deploying IPsec on an eNodeB on a PKI-based secure network



47

In this networking scenario, the UMPT_L provides IPsec for the following data flows:l eNodeB signaling and service data flows.l eNodeB O&M data flows.l Certificate management-related data flows between the eNodeB and CA.l Data