SSL (Sran8.0 02)
SSL (Sran8.0 02)
Issue 02
Date 2013-07-30
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 contract made between Huawei and the
customer. All or part of the products, services and features described in this document may not be within the
purchase 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 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 a warranty of any kind, express or implied.
Website: http://www.huawei.com
Email: support@huawei.com
Contents
2 Overview.........................................................................................................................................3
2.1 Introduction....................................................................................................................................................................3
2.2 Benefits...........................................................................................................................................................................3
2.3 Application.....................................................................................................................................................................3
3 Technical Description...................................................................................................................5
3.1 SSL Protocol Stack.........................................................................................................................................................5
3.2 Procedure for Establishing an SSL Connection.............................................................................................................6
5 Related Features...........................................................................................................................21
5.1 Features Related to SSL (eGBTS Side)........................................................................................................................21
5.2 Features Related to SSL (NodeB Side)........................................................................................................................21
5.3 Features Related to SSL (eNodeB Side).......................................................................................................................22
5.4 Features Related to SSL (Base Station Controller Side)..............................................................................................22
6 Network Impact...........................................................................................................................23
7 Engineering Guidelines on the Base Station Side................................................................24
7.1 When to Use SSL.........................................................................................................................................................24
7.2 Required Information...................................................................................................................................................24
7.3 Planning........................................................................................................................................................................24
7.4 Deployment..................................................................................................................................................................25
7.4.1 Requirements.............................................................................................................................................................25
7.4.2 Data Preparation........................................................................................................................................................25
7.4.3 Precautions.................................................................................................................................................................31
7.4.4 Hardware Adjustment................................................................................................................................................31
7.4.5 Initial Configuration..................................................................................................................................................31
7.4.6 Activation Observation..............................................................................................................................................34
7.4.7 Reconfiguration.........................................................................................................................................................34
7.5 Configuring the OM Channel on the M2000................................................................................................................34
7.6 Performance Monitoring...............................................................................................................................................35
7.7 Parameter Optimization................................................................................................................................................35
7.8 Troubleshooting............................................................................................................................................................35
9 Parameters.....................................................................................................................................47
10 Counters......................................................................................................................................78
11 Glossary.......................................................................................................................................79
12 Reference Documents...............................................................................................................80
1.1 Scope
This document describes SingleRAN Security Socket Layer (SSL),including its technical
principles, related features, network impact, and engineering guidelines.
l Feature change
Changes in features of a specific product version
l 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.
01 (2013-04-28)
This issue does not include any changes.
Draft B (2013-04-10)
This issue includes the following changes.
Draft A (2012-12-30)
This document is created for SRAN8.0.
2 Overview
2.1 Introduction
SSL is a protocol that provides end-to-end communication security by encrypting segments of
network connections at the Application Layer for the Transport Layer that complies with the
TCP protocol. SSL provides security protection for high-layer application protocols, such as
Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), and Telecommunication
Network Protocol (Telnet).
The SSL protocol is the predecessor of Transport Layer Security (TLS). SSL/TLS versions
include SSL1.0, SSL2.0, SSL3.0, TLS1.0, TLS1.1, and TLS1.2. SRAN8.0 supports SSL3.0,
TLS1.0, TLS1.1, and TLS1.2. Higher versions are backward compatible with lower versions.
In this document, SSL is used as a collective name for SSL and TLS.
2.2 Benefits
SSL ensures secure communication between the client and the server by establishing an SSL
connection. SSL provides the following security functions:
2.3 Application
SSL can be used to provide protection for:
l The OM channel between the base station and the M2000 or between the base station
controller and the M2000
l The FTP connection between the base station and the M2000 or between the base station
controller and the M2000.
l The HTTP connection between the base station and the LMT or between the base station
controller and the LMT.
NOTE
Unless otherwise specified, the base station controller in this document is a generic term for GSM and
UMTS modes.
The FTPS components of the M2000 does not support TLS1.2. Therefore, the connection between an NE
and the M2000 does not support TLS1.2.
For detailed descriptions about the application scenarios, see 4 SSL Application Scenarios.
3 Technical Description
l Record layer
The record layer receives data from the application layer or transmits data to the application
layer. In addition, the record layer performs security-related operations, such as
compression/decompression, encryption/decryption, and message authentication code
(MAC) computation.
l Handshake layer
The handshake layer consists of three protocols:
– Handshake protocol
1. The client and the server agree on a set of encryption algorithms, integrity check algorithms,
and keys for the algorithms to secure data transmission.
2. The communication parties can choose whether to authenticate each other.
Figure 3-2 describes the general message exchange process between the client and the server
during an SSL handshake.
Figure 3-2 General message exchange process between the client and the server during an SSL
handshake
1. The client sends a ClientHello message to the server. This message contains the following
information: SSL version, encryption algorithms, signature algorithms, key exchange
algorithms, and MAC algorithms supported by the client.
2. Upon receiving the ClientHello message, the server responds with a ServerHello message.
The ServerHello message contains the SSL version and algorithms selected by the server.
3. (Optional) If the client requests server authentication, the key exchange algorithm field in
the ClientHello message sent in Step 1 instructs the server to send its certificate. The server
then sends a Certificate message containing its certificate to the client.
4. (Optional) If the client does not request server authentication, the server sends a
ServerKeyExchange message to the client. The key contained in this message is used to
encrypt the ClientKeyExchange message sent later in Step 8 . If the client requests server
authentication but the Certificate message sent by the server does not contain complete key
information, the server sends a ServerKeyExchange message to the client to supplement
the key information.
5. (Optional) If the server requests client authentication, the server sends a CertificateRequest
message to the client.
6. The server sends the client a ServerHelloDone message, notifying the client that the
handshake is complete.
7. (Optional) If the client receives a CertificateRequest message from the server, the client
sends a Certificate message containing its certificate to the server.
8. The client sends a ClientKeyExchange message to the server. This message contains the
data for generating the keys for encryption algorithms and integrity check algorithms. The
data is encrypted using the key information described in Step 4 .
9. (Optional) If the client receives a CertificateRequest message from the server, the client
sends a CertificateVerify message which is signed by the private key associated with its
certificate to the server.
10. The client sends the server a ChangeCipherSpec message, notifying the server that the client
will use the negotiated algorithms for subsequent communications.
11. The client sends a Finished message to the server. The message is the first message that is
sent by the client and that is protected by using the negotiated algorithms. This message
contains the MAC of all messages transmitted during the handshake. The MAC is used to
check whether handshake messages have been tampered with during transmission.
12. The server sends the client a ChangeCipherSpec message, notifying the client that the server
will use the negotiated algorithms for subsequent communications.
13. The server sends the client a Finished message. The message is the first message that is
sent by the server and that is protected by using the negotiated algorithms.
After the handshake phase is complete, the client and the server begin to transmit data with SSL
protection.
4.1 OM Channel
SSL can be used to secure the data transmitted on the OM channel between the base station and
the M2000, and between the base station controller and the M2000.
Figure 4-1 Network topology for SSL applied to the OM channel between the base station and
the M2000
Before you configure SSL in this application scenario, you must set the connection type between
the M2000 and the base station to SSL and set the authentication method to "authenticate the
peer end" on the M2000. In addition, preconfigure the operator-issued device certificate and the
operator's root certificate on the M2000.
NOTE
Before establishing an SSL connection, the base station needs to obtain the operator-issued device
certificate and the operator's root certificate from the operator's public key infrastructure (PKI) system. For
details about how to obtain the certificates, see PKI Feature Parameter Description.
Step 1 The base station and the M2000 establish a TCP connection.
Step 2 The M2000 functions as an SSL client and initiates an SSL handshake with the base station.
Step 3 The M2000 authenticates the base station using the specified authentication method during the
SSL handshake. Whether the base station authenticates the M2000 depends on the configuration
file of the base station. After the authentication is successful, the base station and the M2000
establish an OM channel protected by SSL.
----End
NOTE
When using plug and play (PnP) for base station deployment, the M2000 can choose whether to authenticate
the base station. The base station does not authenticate the M2000 by default.
When an OM channel is protected by IPSec, the process of establishing an SSL connection on the OM
channel is the same as the previously mentioned process.
The SSL authentication method of the OM channel between the base station and the M2000 is
determined by both the M2000 and the base station, as described in Table 4-1 .
Table 4-1 SSL authentication method of the OM channel between the base station and the M2000
NOTE
When the PKI system is deployed in the operator's network, it is recommended that the base station and
the M2000 use operator-issued device certificates to authenticate each other.
When no PKI system is deployed in the operator's network, the base station and the M2000 can use only
Huawei-issued device certificates to authenticate each other or they do not authenticate each other.
Figure 4-2 Network topology for SSL applied to the OM channel between a single-mode base
station and the M2000
The WMPT, which is the main control board of the NodeB, does not support certificate
deployment. If the M2000 chooses to authenticate the NodeB, the WMPT must share the
certificates of the UTRPc. For details about certificate sharing, see PKI Feature Parameter
Description.
Figure 4-3 uses the scenario in which different modes of a separate-MPT GSM/UMTS/LTE
multimode base station share the same IPSec tunnel as an example to describe certificate sharing.
Figure 4-3 Network topology for SSL applied to the OM channels between the separate-MPT GSM/UMTS/LTE
multimode base station and the M2000
As shown in Figure 4-2, the operator-issued device certificate and the operator's root certificate
of multimode base station 1 are deployed on the UMPT_L. If the NodeB and the M2000 want
to establish an SSL connection and the operator-issued device certificate will be used for
authentication, the UMPT_U needs to share the certificates of the UMPT_L through backplane.
The operator-issued device certificate and the operator's root certificate of multimode base
station 2 are deployed on the UTRPc. If two SSL connections need to be established between
the NodeB and the M2000 and between the eNodeB and the M2000, and the operator-issued
device certificate will be used for authentication, then the UMPT_U and UMPT_L need to share
the certificates of the UTRPc through backplane.
Figure 4-4 Network topology for SSL applied to the OM channel between the co-MPT multimode base station and
the M2000
For a hybrid-MPT multimode base station, OM channels need to be established between each
separate-MPT main control board and the M2000, and between the co-MPT main control board
and the M2000.
Table 4-2 SSL authentication method of the OM channel between the base station controller
and the M2000
The base station Anonymous The AUTHMODE Both the base station
controller and the Authentication parameter is set to controller and the
M2000 do not NONE(Verify M2000 support the
authenticate each None). same anonymous
other. authentication
algorithm.
Only the M2000 OSS Authentication The AUTHMODE l The OMU board
authenticates the NE parameter is set to of the base station
base station NONE(Verify controller is
controller. None). preconfigured
with the Huawei-
issued device
certificate and the
Huawei root
certificate.
l The M2000 is
preconfigured
with the Huawei
root certificate.
The base station OSS Authentication The AUTHMODE Both the M2000 and
controller and the NE parameter is set to the OMU board of
M2000 authenticate PEER(Verify Peer the base station
each other. Certificate). controller are
preconfigured with
the Huawei-issued
device certificate and
the Huawei root
certificate.
Only the base station NE Authentication The AUTHMODE l The OMU board
controller OSS parameter is set to of the base station
authenticates the PEER(Verify Peer controller is
M2000. Certificate). preconfigured
with the Huawei
root certificate.
l The M2000 is
preconfigured
with the Huawei-
issued device
certificate and the
Huawei root
certificate.
From SRAN7.0 onwards, the base station controller is preconfigured with Huawei-issued device
certificate and Huawei root certificate before delivery. All base station controllers are
preconfigured with the same Huawei-issued device certificate and the same Huawei root
certificate.
If the base station controller is not preconfigured with Huawei-issued device certificate or
Huawei root certificate but the M2000 requests to authenticate the base station controller, the
base station controller and the M2000 first establish a non-SSL-protected OM channel or an OM
channel with SSL anonymous authentication. Then, the engineering personnel obtain the
Huawei-issued device certificate and Huawei root certificate for the base station controller from
the website http://support.huawei.com. Then, they configure these certificates on the base
station controller by using the certificate management function on the M2000. Finally, the
engineering personnel modify the SSL connection type and authentication method on both the
M2000 and the base station controller sides.
For details about certificates for the base station controller, see Base Station Controller
Equipment and OM Security Feature Parameter Description.
The base station functions as the FTPS client. l The ENCRYMODE parameter specifies
the transmission encryption mode of the
base station.
l The SSLCERTAUTH parameter
specifies whether to perform SSL
authentication on the FTPS server.
l The SPTSTATEFWL parameter
specifies whether an FTPS connection can
be set up when a state firewall is
configured.
FTPS is mainly applicable to the file transmission between the base station and the M2000,
between the base station and the base station controller, and between the base station controller
and the M2000.
NOTE
The certificates used for FTPS authentication are the same as those used for SSL authentication of the OM
channel.
Table 4-4 Mapping between the value of the POLICY parameter and the login policy of the
LMT
NOTE
The default value of the POLICY parameter is HTTPS_ONLY, indicating that HTTPS must be used in
both the login page and the LMT operation window.
The certificates used for HTTPS authentication are the same as those used for SSL authentication of the
OM channel. The corresponding root certificate must be preconfigured on the LMT. Otherwise, when you
attempt to log in to the LMT, a dialog box is displayed, indicating that the certificate is unreliable and
asking whether to continue. If you select Yes, you can log in to the LMT.
HTTPS can also apply to the Certificate Management Protocol v2 (CMPv2) message interaction
between the base station and the Certificate Authority (CA) server.
5 Related Features
When certificates are required for SSL authentication, this feature requires the GBFD-113526
BTS Supporting PKI feature.
Impacted Features
None
Impacted Features
None
Impacted Features
None
Impacted Features
None
6 Network Impact
System Capacity
No impact.
Network Performance
When SSL is used to provide encryption and integrity protection, the network bandwidth
utilization decreases slightly. For example, if the application-layer data length is 500 bytes and
the encryption algorithm and integrity check algorithm are 3DES and SHA1, respectively, the
network bandwidth utilization decreases by 4%. 3DES stands for Triple Data Encryption
Standard and SHA1 stands for Secure Hash Algorithm 1.
When certificates are required for SSL authentication, the PKI feature must be activated on the
base station side. For details about how to activate the PKI feature, see PKI Feature Parameter
Description.
7.3 Planning
RF Planning
N/A
Network Planning
N/A
Hardware Planning
Table 7-1 describes the hardware required for deploying SSL on eGBTSs, NodeBs, and
eNodeBs.
Table 7-1 Hardware required for deploying SSL on eGBTSs, NodeBs, and eNodeBs
7.4 Deployment
7.4.1 Requirements
l If the operator-issued device certificate is used for SSL authentication, the PKI system
needs to be deployed in the network and the PKI feature needs to be activated on the base
station side. For details about how to deploy the PKI system, see PKI Feature Parameter
Description.
l If the Huawei-issued device certificate is used for SSL authentication, the PKI feature needs
to be activated on the base station side but the PKI system is not required in the network.
l The
recommend
ed value of
this
parameter
is ALL(All
Type).
2. Collect data in the SSL MO for the SSL authentication method of the OM channel. The
most important parameter in this MO is described in the following table. The SSL MO can
be configured and managed only on the M2000.
3. Collect data in the APPCERT and APPCER MOs. The parameters in these MOs specify
the device certificate used for SSL authentication of the base station.
NOTE
Before activating the SSL feature on a separate-MPT multimode base station, configure SSL data for each
mode separately.
Before activating the SSL feature on a co-MPT multimode base station, configure only a set of SSL data,
which is shared by different modes of the base station.
7.4.3 Precautions
None
Using the CME to Perform Batch Configuration for Newly Deployed Base Stations
Enter the values of the parameters listed in Table 7-7 in a summary data file, which also contains
other data for the new base stations to be deployed. Then, import the summary data file into the
CME for batch configuration.
The summary data file may be a scenario-specific file provided by the CME or a customized
file, depending on the following conditions:
l The MOs in Table 7-7 are contained in a scenario-specific summary data file. In this
situation, set the parameters in the MOs, and then verify and save the file.
l Some MOs in Table 7-7 are not contained in a scenario-specific summary data file. In this
situation, customize a summary data file to include the MOs before you can set the
parameters.
NOTE
During base station deployment by PnP, you can also set the Connection Type and Authentication Type
parameters in the PnP Parameters MO on the Auto Deployment sheet of a scenario-specific summary
data file.
For detailed operations on each type of base station, see the following sections in 3900 Series
Base Station Initial Configuration Guide:
Using the CME to Perform Batch Configuration for Existing Base Stations
Batch reconfiguration using the CME is the recommended method to activate a feature on
existing base stations. This method reconfigures all data, except neighbor relationships, for
multiple base stations in a single procedure. The procedure is as follows:
Step 1 Choose CME > Advanced > Customize Summary Data File from the main menu of an M2000
client, or choose Advanced > Customize Summary Data File from the main menu of a CME
client, to customize a summary data file for batch reconfiguration.
NOTE
Step 2 Export the NE data stored on the CME into the customized summary data file.
l For co-MPT multimode base stations: Choose CME > SRAN Application > MBTS
Application > Export Data > Export Base Station Bulk Configuration Data from the
main menu of the M2000 client, or choose SRAN Application > MBTS Application >
Export Data > Export Base Station Bulk Configuration Data from the main menu of the
CME client.
l For separate-MPT GSM-involved multimode base stations or GO base stations: Choose
CME > GSM Application > Export Data > eGBTS Bulk Configuration Data from the
main menu of the M2000 client, or choose GSM Application > Export Data > Export
eGBTS Bulk Configuration Data from the main menu of the CME client.
l For separate-MPT UMTS-involved multimode base stations or UO base stations: Choose
CME > UMTS Application > Export Data > Export Base Station Bulk Configuration
Data from the main menu of the M2000 client, or choose UMTS Application > Export
Data > Export Base Station Bulk Configuration Data from the main menu of the CME
client.
l For separate-MPT LTE-involved multimode base stations or LO base stations: Choose CME
> LTE Application > Export Data > Export Base Station Bulk Configuration Data from
the main menu of the M2000 client, or choose LTE Application > Export Data > Export
Base Station Bulk Configuration Data from the main menu of the CME client.
Step 3 In the summary data file, set the parameters in the MOs listed in Table 7-7 and close the file.
the main menu of the M2000 client, or choose LTE Application > Import Data > Import
Base Station Bulk Configuration Data from the main menu of the CME client.
----End
7.4.7 Reconfiguration
N/A
Step 1 Log in to the M2000, choose Security > Certificate Authentication Management > SSL
Connection Management (traditional style) or Security Management > NE Security >
Certificate Authentication Management > SSL Connection Management (application style)
to open the SSL connection management window.
Step 2 In the left pane, select the base station to configure. In the right pane, set the connection type
and authentication method, as shown in Figure 7-1.
----End
For more information about managing NE certificates and preconfiguring certificates on the
M2000, see the "Procedure for Configuring Digital Certificates" section in M2000 Online
Help (Security Management > Data Management > Configuring Digital Certificates).
To check the status of an SSL connection between the base station and the M2000, select the
base station in the SSL connection management window and then check the value of the
Connection Status field. If the value of this field is Connected, an SSL connection has been
successfully established.
7.8 Troubleshooting
After the SSL feature is activated, the base station may report the following alarm:
ALM-25950 Excessive Flood Packet; the value of the Specific Problem parameter in the alarm
help is SSL Renegotiation.
After the PKI feature is activated, the base station may report the following alarms:
For details about how to locate and analyze the problem, see 3900 Series Base Station Alarm
Reference.
8.3 Planning
RF Planning
N/A
Network Planning
N/A
Hardware Planning
N/A
8.4 Deployment
8.4.1 Requirements
If certificates are required to authenticate the SSL connection of the OM channel, ensure that
the device certificate and root certificate have been preconfigured on the OMU board of the base
station controller.
For details about how to config the certificates for the base station controller, see Configuring
the Digital Certificates in Base Station Controller Equipment and OM Security Feature
Parameter Description.
2. Collect data in the SSLAUTHMODE MO for the SSL authentication method of the OM
channel. The most important parameter in this MO is described in the following table.
3. Collect data in the CERTFILE MO. The parameters in this MO specify the certificates
used for SSL authentication.
FTPSCLT Support State Firewall SPTS Set this parameter Network plan
TATE based on the
FWL network plan.
(
BSC6
900,
BSC6
910)
FTPSSRV The Source SRVDATAPOR Set this parameter only when Network
Data Port T the DFTPORTSWT plan
of FTP (BSC6900, (BSC6900,BSC6910)
Server BSC6910) parameter is set to
CUSTOMPORT.
8.4.3 Precautions
None
Step 1 Run the MML command SET SSLAUTHMODE to set the SSL authentication method.
Step 2 Run the MML command SET CERTFILE to configure the certificates used for SSL
authentication.
----End
Check whether log files are being transmitted between the base station controller and the
M2000 as expected. If log file transmission is normal, an FTPS connection has been
successfully established between the base station controller and the M2000.
l Base station controller functioning as the FTPS server
Check whether log files are properly transmitted between the base station controller and
the M2000 based on FTPS. If log files are properly transmitted, an FTPS connection has
been successfully established between the base station controller and the M2000.
l HTTPS connection between the base station controller and the LMT
Set the login policy of the LMT for the base station controller to HTTPS and Log in to the
base station controller from the LMT. If you can successfully log in to the base station
controller, an HTTPS connection has been successfully established between the base station
controller and the LMT.
8.4.7 Reconfiguration
N/A
Step 1 Log in to the M2000, choose Security > Certificate Authentication Management > SSL
Connection Management (traditional style) or Security Management > NE Security >
Certificate Authentication Management > SSL Connection Management (application style)
to open the SSL connection management window.
Step 2 In the left pane, select the base station controller to be configured. In the right pane, set the
connection type and authentication method, as shown in Figure 8-1.
----End
Figure 8-1 Changing the SSL configuration of an existing base station controller
For more information about managing NE certificates and preconfiguring certificates on the
M2000, see the "Procedure for Configuring Digital Certificates" section in M2000 Online
Help (Security Management > Data Management > Configuring Digital Certificates >).
To check the status of an SSL connection between the base station controller and the M2000,
select the base station controller in the SSL connection management window and then check the
value of the Connection Status field. If the value of this field is Connected, an SSL connection
has been successfully established.
8.8 Troubleshooting
After the SSL feature is activated, the base station controller may report the following alarm:
For details about how to locate and analyze the problem, see the following documents:
9 Parameters
the certificate
verification
fails, the SSL
connection
cannot be set up.
GUI Value
Range:NONE
(Verify None),
PEER(Verify
Peer Certificate)
Unit:None
Actual Value
Range:NONE,
PEER
Default
Value:NONE
(Verify None)
Default
Value:Auto
(Auto)
GUI Value
Range:No(No),
Yes(Yes)
Unit:None
Actual Value
Range:No, Yes
Default
Value:Yes(Yes)
Default
Value:AUTO
(Automatic)
Default
Value:AUTO
(Automatic)
HTTPS_ONLY
(Https_only),
LOGIN_HTTP
S_ONLY
(Login_https_o
nly)
Unit:None
Actual Value
Range:COMPA
TIBLE,
HTTPS_ONLY,
LOGIN_HTTP
S_ONLY
Default
Value:HTTPS_
ONLY
(Https_only)
Actual Value
Range:DEFAU
LTPORT,
CUSTOMPOR
T
Default
Value:DEFAUL
TPORT(Default
21 Port)
Actual Value
Range:DEFAU
LTPORT,
CUSTOMPOR
T
Default
Value:DEFAUL
TPORT(Default
21 Port)
10 Counters
11 Glossary
12 Reference Documents