GSM/EDGE BSS, Operating

Documentation
Radio Access

BSC TRANSPORT SITE SOLUTION

RG20

Daughter Document

External Security Gateway

DN0976647

Issue 01C

Approval Date 2011-02-03

BSC TRANSPORT SITE SOLUTION Introduction

The information in this document applies solely to the hardware/software product (“Product”) specified herein, and only as
specified herein.
This document is intended for use by Nokia Networks' customers (“You”) only, and it may not be used except for the
purposes defined in the agreement between You and Nokia Networks (“Agreement”) under which this document is
distributed. No part of this document may be used, copied, reproduced, modified or transmitted in any form or means without the
prior written permission of Nokia Networks. If you have not entered into an Agreement applicable to the Product, or
if that Agreement has expired or has been terminated, You may not use this document in any manner and You are obliged to
return it to Nokia Networks and destroy or delete any copies thereof.
The document has been prepared to be used by professional and properly trained personnel, and You assume full responsibility
when using it. Nokia Networks welcome Your comments as part of the process of continuous development and
improvement of the documentation.
This document and its contents are provided as a convenience to You. Any information or statements concerning the suitability,
capacity, fitness for purpose or performance of the Product are given solely on an “as is” and “as available” basis in this document,
and Nokia Networks reserves the right to change any such information and statements without notice. Nokia
Networks has made all reasonable efforts to ensure that the content of this document is adequate and free of material
errors and omissions, and Nokia Networks will correct errors that You identify in this document. But, Nokia
Networks' total liability for any errors in the document is strictly limited to the correction of such error(s). Nokia
Networks does not warrant that the use of the software in the Product will be uninterrupted or error-free.
NO WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY OF AVAILABILITY,
ACCURACY, RELIABILITY, TITLE, NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, IS MADE IN
RELATION TO THE CONTENT OF THIS DOCUMENT. IN NO EVENT WILL NOKIA NETWORKS BE LIABLE FOR ANY
DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDIRECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH
AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA THAT MAY
ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT, EVEN IN THE CASE OF ERRORS IN OR OMISSIONS FROM
THIS DOCUMENT OR ITS CONTENT.
This document is Nokia Networks’ proprietary and confidential information, which may not be distributed or
disclosed to any third parties without the prior written consent of Nokia Networks.
Nokia is a registered trademark of Nokia Corporation. Other product names mentioned in this document may be trademarks of
their respective owners, and they are mentioned for identification purposes only.
Copyright © 2014 Nokia Networks. All rights reserved.

Important Notice on Product Safety

This product may present safety risks due to laser, electricity, heat, and other sources of danger.
Only trained and qualified personnel may install, operate, maintain or otherwise handle this product and only after having carefully
read the safety information applicable to this product.
The safety information is provided in the Safety Information section in the “Legal, Safety and Environmental Information” part of
this document or documentation set.

Nokia Networks is continually striving to reduce the adverse environmental effects of its products and services. We
would like to encourage you as our customers and users to join us in working towards a cleaner, safer environment. Please recycle
product packaging and follow the recommendations for power use and proper disposal of our products and their components.
If you should have questions regarding our Environmental Policy or any of the environmental services we offer, please contact us
at Nokia Networks for any additional information.

DN0976647 © 2014 Nokia Networks 2 / 78

Issue 01C
Table of contents

Table of contents

1 Introduction ..................................................................................................... 8
1.1 Target and scope ............................................................................................ 8

2 Concepts....................................................................................................... 10
2.1 Abbreviations ................................................................................................ 10
2.2 Concepts and terminology............................................................................. 12

3 References ................................................................................................... 13

4 IPSEC in GSM-EDGE RAN Overview ........................................................... 15

5 Juniper NetScreen Series ............................................................................. 17

5.1 Juniper NetScreen Architecture..................................................................... 17
5.1.1 Overview ....................................................................................................... 17
5.1.2 Management Module (MGTs) ....................................................................... 20
5.1.3 Secure Port Modules (SPM) .......................................................................... 20
5.1.4 NetScreen transceivers (SFP and XFP) ........................................................ 21
5.2 Recommended configuration ........................................................................ 21
5.3 Juniper NetScreen functions and concepts ................................................... 22
5.3.1 Security zones .............................................................................................. 22
5.3.2 Security zones interfaces .............................................................................. 23
5.3.3 Virtual routers................................................................................................ 25
5.3.4 Policies ......................................................................................................... 25
5.3.5 VPN .............................................................................................................. 26
5.3.6 PKI ................................................................................................................ 26
5.3.7 Firewall ......................................................................................................... 26
5.3.8 High Availability............................................................................................. 27
5.3.9 Management ................................................................................................. 31
5.4 NetScreen Performances .............................................................................. 33
5.4.1 NetScreen-5200 ............................................................................................ 33

6 BSC site solution: SGW Setup ...................................................................... 35

6.1 Installation ..................................................................................................... 35

DN0976647 © 2014 Nokia Networks 3 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Introduction

6.2 SGW provisioning ......................................................................................... 38

6.2.1 General ......................................................................................................... 38
6.2.2 HA provisioning ............................................................................................. 44
6.2.3 Routing table provisioning ............................................................................. 47
6.2.4 OSPF provisioning ........................................................................................ 47
6.2.5 VPN provisioning........................................................................................... 48
6.2.6 Packet Abis VPN provisioning ....................................................................... 49
6.2.7 Example of VPN provisioning ........................................................................ 55
6.3 Firewall provisioning ...................................................................................... 67
6.3.1 Basic filtering rules ........................................................................................ 68
6.3.2 Additional defence mechanisms .................................................................... 71

7 SGW Requirements Compliance ................................................................... 76

DN0976647 © 2014 Nokia Networks 4 / 78

Issue 01C
List of Figures

List of Figures

Figure 1: BSC Transport Site Solution documentation structure ................................... 9

Figure 2: IPSec in GSM-EDGE RAN........................................................................... 16
Figure 3: Juniper NetScreen series ............................................................................. 17
Figure 4: Security zones in Nokia GSM RAN.............................................................. 23
Figure 5: VSD group & VSI (no M-plane separation) ................................................... 30
Figure 6: Management module ports .......................................................................... 32
Figure 7: SGW physical layout in BSC site solution with active/active redundancy ..... 36
Figure 8: SGW physical layout in BSC site solution with active/active redundancy with
link aggregation .......................................................................................................... 37
Figure 9: SGW physical layout in BSC site solution with active/active redundancy with
separated L3 interfaces .............................................................................................. 38
Figure 10: Packet Abis vpn (outer IP endpoints) ......................................................... 41
Figure 11: Packet Abis, AoIP/ETPSIG and SIGTRAN vpn (with active/active SGW
configuration) .............................................................................................................. 42
Figure 12: Packet Abis, AoIP/ETPSIG and SIGTRAN vpn (with m-plane separation and
active/active SGW configuration) ................................................................................ 43
Figure 13: HA configuration overview example (without m-plane separation) ............. 45
Figure 14: HA configuration overview example (with M-plane separation) .................. 46
Figure 15: Packet Abis relationships among traffic flows, IP endpoints and IPsec
security associations ................................................................................................... 50
Figure 16: Traffic type, SA, inner/outer IP endpoints relationship ................................ 51
Figure 17: Traffic not managed by Firewall ................................................................. 67

DN0976647 © 2014 Nokia Networks 5 / 78

Issue 01C
List of Tables

List of Tables

Table 1: Modules Supported by Each Slot in a NetScreen-5000 Series Device ................... 18

Table 2: Configurations for Management and Secure Port Modules .................................... 19
Table 3: NetScreen 5000-series Management Modules ....................................................... 20
Table 4: Packet Abis Security measures .............................................................................. 39
Table 5: NSRP configuration (without m-plane separation) .................................................. 45
Table 6: NSRP configuration (with M–plane)........................................................................ 47
Table 7: Hints to configure the security associations for Packet Abis traffic.......................... 52
Table 8: SGW policy-based VPN configuration: example (Use Case B1) for Packet Abis
interface ............................................................................................................................... 61
Table 9: SGW policy-based VPN configuration: example (Use Case B1) for Packet Abis
interface (continued) ............................................................................................................ 62
Table 10: SGW route-based VPN configuration: example (Use Case B1) for Packet Abis
interface ............................................................................................................................... 63
Table 11: SGW route-based VPN configuration: example (Use Case B1) for Packet Abis
interface (continued) ............................................................................................................ 64
Table 12: SGW policy-based VPN configuration example for AoIP, external ETPSIG,
SIGTRAN interface .............................................................................................................. 65
Table 13: SGW policy-based VPN configuration example for SIGTRAN-BBI interface......... 66
Table 14: Filtering rules........................................................................................................ 69

DN0976647 © 2014 Nokia Networks 6 / 78

Issue 01C
Summary of changes

Summary of changes
Changes between document issues are cumulative. Therefore, the latest document issue contains all
changes made to previous issues.

Changes made between issues 01C and 01B

Updated the document with a work around for Juniper in section Example of VPN provisioning.

Changes made between issues 01B and 01A

Updated the document with some editorial changes.

DN0976647 © 2014 Nokia Networks 7 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Introduction

1 Introduction

1.1 Target and scope

The present document is part of a set of documents describing the BSC Site
Solution for RG20/BSS15 (see Figure 1 for the related documentation
structure).

The aim of the document is to describe the recommended external Security

Gateway type(s) to be used to protect traffic with IPsec over transport
(backhaul/backbone) networks in the GSM-EDGE RAN.

This document describes the Security Gateway Recommended for BSC Site
Solution in terms of:
• Security Gateway High level Description
• Setup and configuration (not the used commands) in relation to the
reference Network Scenarios/use cases as listed in the BSC Site
Solution Mother Document /A/.

DN0976647 © 2014 Nokia Networks 8 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Introduction

Figure 1: BSC Transport Site Solution documentation structure

DN0976647 © 2014 Nokia Networks 9 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Concepts

2 Concepts

2.1 Abbreviations
ABBR Explanation

CBC Cell Broadcast Center

DMZ De-Militarized Zone

ESP Encapsulating Security Payload

HA High Availability

IKE Internet Key Exchange

MGT Management Module

NAT Network Address Translation

NSRP NetScreen Redundancy Protocol

OSPF Open Shortest Path First

PDM Packet Delay Measurement

PPS Packets-per-Second

QoS Quality of Service

SA Security Association

DN0976647 © 2014 Nokia Networks 10 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Concepts

SFP Small Form-Factor Pluggable Unit

SGW Security Gateway

SPM Secure Port Modules

VPN Virtual Private Network

VSD Virtual Security Device

VSI Virtual Security Interface

VSYS Virtual System

DN0976647 © 2014 Nokia Networks 11 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Concepts

2.2 Concepts and terminology

Concept\Term Description
small form-factor The small form-factor pluggable (SFP) is a compact, hot-pluggable
pluggable (SFP) transceiver used for both telecommunication and data
communications applications. It interfaces a network device mother
board (for a switch, router, media converter or similar device) to a
fiber optic or copper networking cable. It is a popular industry format
supported by many network component vendors.
Encapsulating Encapsulating Security Payload (ESP) is a member of the IPsec
Security Payload protocol suite. In IPsec it provides origin authenticity, integrity, and
(ESP) confidentiality protection of packets.
Cell Broadcast It is the center responsible for Cell Broadcast (CB) messaging. Cell
messaging center Broadcast messaging is a mobile technology feature defined by the
(CBC) ETSI’s GSM committee and is part of the GSM standard. It is also
known as Short Message Service - Cell Broadcast (SMS-CB). Cell
Broadcast is designed for simultaneous delivery of messages to
multiple users in a specified area.
De-militarized zone A de-militarized zone is a physical or logical subnetwork that
(DMZ) contains and exposes an organization's external services to a larger
untrusted network, usually the Internet. It is sometimes referred to
as a Perimeter Network. The purpose of a DMZ is to add an
additional layer of security to an organization's Local Area Network
(LAN); an external attacker only has access to equipment and
services in the DMZ, rather than any other part of the network.
VIrtual system Some Juniper Networks security devices support virtual systems
(VSYS) (vsys). A virtual system is a subdivision of the main system that
appears to the user to be a standalone entity. Virtual systems
reside separately from each other and from the root system within
the same security device.
Internet Key Internet Key Exchange (IKEv1 or IKEv2) is the protocol used to set
Exchange up a security association (SA) in the IPsec protocol suite. IKE builds
upon the Oakley protocol and ISAKMP and uses a Diffie–Hellman
key exchange to set up a shared session secret, from which
cryptographic keys are derived. Public key techniques or,
alternatively, a pre-shared key, are used to mutually authenticate
the communicating parties.

DN0976647 © 2014 Nokia Networks 12 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION References

3 References

Public references:
Standards, publications
/1/ NetScreen-5000 Series Hardware Installation and Configuration
Guide
http://www.juniper.net/techpubs/en_US/release-
independent/screenos/information-products/pathway-
pages/netscreen-series/product/index.html

/2/ ScreenOS Reference Guide - Virtual Private Networks

Release 6.3.0
http://www.juniper.net/techpubs/en_US/screenos6.3.0/information-
products/pathway-pages/screenos/index.html

/3/ ScreenOS Reference Guide - High Availability

Release 6.3.0

http://www.juniper.net/techpubs/en_US/screenos6.3.0/information-
products/pathway-pages/screenos/index.html

/4/ ScreenOS Reference Guide - Attack Detection and Defense

Mechanisms
Release 6.3.0

http://www.juniper.net/techpubs/en_US/screenos6.3.0/information-
products/pathway-pages/screenos/index.html

/5/ ScreenOS Reference Guide- Fundamentals

DN0976647 © 2014 Nokia Networks 13 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION References

Release 6.3.0
http://www.juniper.net/techpubs/en_US/screenos6.3.0/information-
products/pathway-pages/screenos/index.html

/6/ ScreenOS Reference Guide-Routing

Release 6.3.0
http://www.juniper.net/techpubs/en_US/screenos6.3.0/information-
products/pathway-pages/screenos/index.html

/7/ ScreenOS Reference Guide-Administration

Release 6.3.0
http://www.juniper.net/techpubs/en_US/screenos6.3.0/information-
products/pathway-pages/screenos/index.html

DN0976647 © 2014 Nokia Networks 14 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION IPSEC in GSM-EDGE RAN Overview

4 IPSEC in GSM-EDGE RAN Overview

GSM Network can be backhauled with IP/Eth. Mobile Network Operator may
use third party service providers for backbone and backhaul. IPsec can be
used to protect the BSC traffic against fake senders, traffic manipulation and
eavesdropping.

Nokia Recommends Juniper NetScreen Series as SGW.

Overview of Nokia solution is provided in BSC Site Solution Mother Document

/A/.

DN0976647 © 2014 Nokia Networks 15 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION IPSEC in GSM-EDGE RAN Overview

BSC provides
integrated IPSEC
only for O&M/CBC

BSC CA/ SSE-M

BSC
Site NetAct (*) BSC Site
CR
Core BSC
SLMC Network NetAct
TCSM
VNP MSS MGW
DCN/BackBone Network
CBC SGSN L3 SGW

MLS SGW
DNS

Backhaul Network
L2 or L3 ATS
MLS
SSE-M
(*)
PTP-M
SSE
Equipment

(*) SSE-M, ATS, PTP-M may be placed in NetAct Site or in CN Site or in BSC Site.

Figure 2: IPSec in GSM-EDGE RAN

DN0976647 © 2014 Nokia Networks 16 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

5 Juniper NetScreen Series

The content of this chapter is a short overview of Juniper NetScreen series.
Please refer to official Juniper documentation for further details (/1/).

5.1 Juniper NetScreen Architecture

5.1.1 Overview

Juniper NetScreen series includes NetScreen-5200 and NetScreen-5400

systems (examples in Figure 3)

M a na gem e nt
m odu le

S e cur e po rt m od ules
Loa d sh arin g ho t
sw a ppa ble po w er
sup plies ( AC o r D C )

Figure 3: Juniper NetScreen series

The NetScreen 5200 systems (“empty Chassis”) are provided with the
following options:

DN0976647 © 2014 Nokia Networks 17 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

• NS-5200: NS-5200 system, no SPM or MGT modules, includes fan

tray, dual AC power supply, 19” rack mount.
• NS-5200-DC: NS-5200 system, no SPM or MGT modules,
includes fan tray, dual DC power supply, 19” rack mount.

The NetScreen 5400 systems (“empty Chassis”) are provided with the
following options:
NS-5400: NS-5400 system, no SPM or MGT modules, includes fan tray, 3 x
AC power supply, 19” rack mount.
NS-5400-DC: NS-5400 system, no SPM or MGT modules, includes fan tray, 3
x DC power supply, 19” rack mount.

The NetScreen-5000 Series systems support two module types:

• NetScreen-5000 management modules (MGTs)
• NetScreen-5000 Secure Port Modules (SPMs)
Table 1 shows the modules supported by each slot.

Table 1: Modules Supported by Each Slot in a NetScreen-5000 Series Device

DN0976647 © 2014 Nokia Networks 18 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

Table 2 shows the configurations for each management module and SPM and
shows whether the firmware version is included on the management module
or if it needs to be downloaded.
Table 2: Configurations for Management and Secure Port Modules

DN0976647 © 2014 Nokia Networks 19 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

5.1.2 Management Module (MGTs)

The management module provides general-purpose CPU delivery and

contains dedicated high availability (HA) and management interfaces. It
handles tasks such as management access, session setup and termination,
and Internet Key Exchange (IKE) negotiation. The management module
assists other system elements, primarily with non-flow related tasks. It
provides overall management and control of the system. Although it performs
system management, the primary function of the management module is to
support the other modules.

Table 3: NetScreen 5000-series Management Modules

5.1.3 Secure Port Modules (SPM)

Secure Port Modules (SPMs) perform general packet processing and device
connection tasks for devices that communicate with the NetScreen-5000
Series. SPMs handle packets as they enter and exit the system, providing
packet parsing, classification, and flow-level processing. SPMs also provide
encryption, decryption, Network Address Translation (NAT), and session
lookup features. When packets require processing beyond that provided by an
SPM, the NetScreen-5000 Series hands them off to the management module
for further processing. There are currently the following families of SPMs:
• The NS-5000-8G2 and NS-5000-8G2-G4 SPMs provide eight 1-
Gigabit Small Form factor Pluggable (SFP) sockets. These SPMs
are supplied with SX gigabit fiber SFP transceivers. These
modules are also capable of supporting a total of four aggregate
interfaces, with up to four ports for each aggregate interface.

DN0976647 © 2014 Nokia Networks 20 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

• The NS-5000-8G2-TX and NS-5000-8G2-G4-TX SPMs provide

eight 1-Gigabit Small Form factor Pluggable (SFP) sockets. These
SPMs are supplied with copper gigabit fiber SFP transceivers.
• The NS-5000-2XGE and NS-5000-2XGE-G4 SPMs provides two
10-Gigabit Form factor Pluggable (XFP) Sockets. You must
purchase transceivers for this SPM separately.

5.1.4 NetScreen transceivers (SFP and XFP)

The following transceivers are available to configure the NetScreen Secure

Port Modules:
• NS-SYS-GBIC-MSX : SX transceiver (mini-GBIC)
• NS-SYS-GBIC-MLX : LX transceiver (mini-GBIC)
• NS-SYS-GBIC-MXSR : XFP 10GigE transceiver Short Range
(SR) (300 m)
• NS-SYS-GBIC-MXLR : XFP 10GigE transceiver Long Range
(LR) (10 km)

5.2 Recommended configuration

Minimum configuration:
• The NetScreen 5400 systems (“empty Chassis”)
• 1 Management Module 5000-MGT3 with following main
characteristics
Firewall session setup performance: 26K+ new sessions per second
VPN tunnel setup performance: Establish 120 IKE tunnels/second with pre-shared keys.
• 1 NetScreen-5000 8G2-G4-TX SPM module with following main
characteristics
8 port mini-GBIC interfaces
8 Gbps Firewall / 4 Gbps 3DES/AES IPsec
4 port link aggregation

DN0976647 © 2014 Nokia Networks 21 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

In alternative in case of higher throughout following module may be

ordered.
• NetScreen-5000 2XGE-G4 SPM module with following main
characteristics
2 x 10 Gig Ethernet XFP Pluggable Interfaces
10 Gbps Firewall / 5 Gbps 3DES/AES IPsec
SR and LR Transceivers available at FCS

5.3 Juniper NetScreen functions and concepts

5.3.1 Security zones

A security zone is a collection of one or more network segments requiring the

regulation of inbound and outbound traffic via policies. Security zones are
logical entities to which one or more interfaces are bound. Multiple security
zones can be defined. For NetScreen operating at layer 3 there are the
following predefined zones: Trust, Untrust, and DMZ.
In Nokia site solution (Figure 4) only the Trust and Untrust zones are relevant.
All devices within BSC site are part of the Trust zone. All external sites (BTSs,
NetAct site, Core Network site, other BSC sites) interconnected with the BSC
site are considered part of the Untrust zone.

DN0976647 © 2014 Nokia Networks 22 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

Untrusted zone
Trusted zone
SLMC CA/
NetAct
CR
BSC
VNP MSS MGW ATS
BSC
TCSM SSM
CBC SGSN
(*)

DNS PTP-M
TCSM

Figure 4: Security zones in Nokia GSM RAN

5.3.2 Security zones interfaces

An interface bound to a security zone can be thought of as a doorway through

which IP traffic can pass between that zone and any other zone. Also multiple
interfaces can be bound to same zone. In general a traffic flow, entering in
NetScreen through an interface bound to a security zone, shall be forwarded
(and, if needed, encrypted) towards a destination being in a different security
zone. Before routing (and, possibly, encrypting) this traffic, NetScreen will
analyze it by means of security policies. Depending on this analysis the traffic
flow will be allowed (for further encryption and forwarding) or blocked.
For traffic to flow between interfaces bound to the same zone, no policy is
required because both interfaces have security equivalency. ScreenOS
requires policies for traffic between zones, not within the same zone.

Interfaces, relevant for Nokia site solution, bound to a security zone may be:
• Physical interface:
A physical interface relates to components that are physically
present on the security device.
• Subinterface:
On devices that support virtual LANs (VLANs), a physical interface
can be logically divided into several virtual sub-interfaces, each of
which borrows the bandwidth it needs from the physical interface
from which it stems. A sub-interface is an abstraction that functions
identically to a physical interface and is distinguished by 802.1Q
VLAN tagging. The security device directs traffic to and from a
zone with a sub-interface via its IP address and VLAN tag.
• Aggregate Interfaces:

DN0976647 © 2014 Nokia Networks 23 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

Some security devices support aggregate interfaces (link

aggregation). An aggregate interface is the accumulation of two or
more physical interfaces that share the traffic load directed to the
IP address of the aggregate interface equally among them. By
using an aggregate interface, you can increase the amount of
bandwidth available to a single IP address. Also, if one member of
an aggregate interface fails, the other member or members can
continue processing traffic although with less bandwidth than
previously available. Only Secure Port Modules (SPMs) support
this feature, and is possible only aggregate side-by-side ports that
reside on the same module.
• Redundant Interfaces:
It is possible to bind two physical interfaces together to create one
redundant interface, which can then be bound to a security zone.
One of the two physical interfaces acts as the primary interface
and handles all the traffic directed to the redundant interface. The
other physical interface acts as the secondary interface and stands
by in case the active interface experiences a failure. If that occurs,
traffic to the redundant interface fails over to the secondary
interface, which becomes the new primary interface. The use of
redundant interfaces provides a first line of redundancy before
escalating a failover to the device level.
• Management interfaces: see the Management (5.3.9) for details.
• Virtual Security Interfaces: see High availability (5.3.8) for
details.
• High Availability interfaces: see the High Availability (5.3.8) for
details.

In Nokia site solution the following remarks apply:

- Sub-interfaces (and VLAN tagging) will not be used: due to
high throughputs at BSC site it is not expected that sharing the
same physical link between two security zones will introduce
relevant advantages. Moreover it will introduce more
configuration issues.
- Redundant interfaces will not be used, in order to not introduce
non-deterministic behaviors during the device failover phase.
- It is suggested to use aggregate interfaces in order to scale
with link throughput to cope the Customer’s traffic needs.
- High availability interfaces will be used.
- Virtual security interfaces will be used.

DN0976647 © 2014 Nokia Networks 24 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

5.3.3 Virtual routers

In ScreenOS, a security device supports two predefined virtual routers. This

allows the security device to maintain two separate unicast and multicast
routing tables and to conceal the routing information in one virtual router from
the other. For example, the untrust-vr is typically used for communication with
untrusted parties and does not contain any routing information for the
protected zones. Routing information for the protected zones is maintained by
the trust-vr. Thus, no internal network information can be gathered by the
covert extraction of routes from the untrust-vr.

In Nokia site solution the two pre-defined routers ( trust-vr and untrust vr ) are
used.

5.3.4 Policies

Juniper’s security devices secure a network by inspecting, and then allowing

or denying, all connection attempts that require passage from one security
zone to another. By default, a security device denies all traffic in all directions.
Through the creation of policies, you can control the traffic flow from zone to
zone by defining the kinds of traffic permitted to pass from specified sources to
specified destinations.

Every time a packet attempts to pass from one zone to another (or even
between two interfaces bound to the same zone), the security device checks
its policy set lists for a policy that permits such traffic. To allow traffic to pass
from one security zone to another—for example, from zone A to zone B—you
must configure a policy that permits zone A to send traffic to zone B. To allow
traffic to flow the other way, you must configure another policy permitting
traffic from zone B to zone A. For any traffic to pass from one zone to another
there must be a policy that permits it. Also, if intrazone blocking is enabled,
there must be a policy to permit traffic to pass from one interface to another
within that zone.

In Nokia site solution the policies are used to:

− Identify the traffic to be secured/unsecured traffic through IPsec
tunnels. For this purpose the policy-based tunnel configuration is
suggested.
− Allow/block unsecured traffic between security zones, by filtering it
by IP address, protocol, ports.
Intrazone policies are not needed because the traffic within the untrust zone
(i.e. CMP and LDAP traffic between BTS and Certification Authority) is routed
directly by multi-layer switch (see 6.3).

DN0976647 © 2014 Nokia Networks 25 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

5.3.5 VPN

Juniper NetScreen supports IPsec technology for creating VPN tunnels.

Two two kinds of key creation mechanisms are supported:
• Manual Key
• AutoKey IKE (IKEv1 and IKEv2) with a pre-shared key or
certificate.
See Juniper Documentation /2/ for details.
In Nokia site solution:
− NetScreen, for VPN established towards BTS, will use only
IKEv2 together with X509 certificates.
− IKEv1 (with a pre-shared key or certificate) or manual key
could be used towards Core Network’s security
gateways.Manual key and IKEv1 with pre-shared key are not
expected to be used in practice.

5.3.6 PKI

Juniper NetScreen supports PKI. See Juniper Documentation /2/ for details.

5.3.7 Firewall

Juniper NetScreen supports integrated firewall. See Juniper Documentation

/4/ for details.

More in general traffic policing takes place at two levels:

• Through the so-called “SCREEN options”, at the security zone
level.
• Through the firewall policies, at the inter-zone level.
See also section 6.3.

In Nokia site solution both the SCREEN options and the firewall policies, at the
inter-zone level are recommended (see section 6.3.)

DN0976647 © 2014 Nokia Networks 26 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

5.3.8 High Availability

A proprietary mechanism is implemented and a brief summary is provided

here. See Juniper Documentation /3/ for details.

Because all of network traffic passes through a NetScreen device, it should be

avoided that it becomes a single point of failure. For this, NetScreen’s High
availability (HA) feature allows configuring a pair of NetScreens in an
active/active or active/standby device’s redundancy schema.

The protocol managing this kind of redundancy is the proprietary NetScreen

Redundancy Protocol (NSRP).

Key concepts of NSRP are:

• Active/active redundancy
Both devices process traffic (i.e. each device handles 50% of the
traffic). Active/standby means, instead, that only one of the
devices (i.e. the active device) handles the 100% of the traffic .The
standby device, instead, will take over the all of the traffic in case
of failure of the active device.
In Nokia BSC site solution the NSRP cluster shall be configured as
active/active.
• Synchronization of Real Time Objects.
NSRP provides synchronization the so called Real Time Objects
(RTOs) between the redundant devices: examples of RTOs are
IPsec Phase 2 security associations (SAs), ARP tables, DNS
caches etc. This allows the minimum of traffic disruption when one
of the NetScreens fails.
Real Time Objects synchronization is required in BSC site solution.
• NSRP cluster.
The redundant devices shall be member of the same NSRP
cluster. An NSRP cluster consists of a group of security devices
that enforce the same overall security policy and share the same
configuration settings. When you assign a device to an NSRP
cluster, any changes made to the configuration on one member of
the cluster propagate to the others. Members of the same NSRP
cluster maintain the following identical settings:
Policies;
System parameters (such as settings for authentication servers, DNS, SNMP, syslog, Web
filtering, firewall detection options, and so on);

DN0976647 © 2014 Nokia Networks 27 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

In Nokia BSC site solution the NSRP cluster will contain two
security devices.
• Virtual security device (VSD) groups and Virtual Security
Interfaces (VSI)
Virtual security device (VSD) groups are created each with its own
virtual security interfaces (VSIs). It is possible to assign two
NetScreen devices to one or more VSD groups. In each single
group, one of the devices is defined as primary (i.e. it processes
the traffic within the group) and the other one as secondary (i.e. it
does not process any traffic until the primary device goes out of
service). The role of primary/secondary NetScreen device inside a
VSD group is assigned by means of a priority value. The device
with the priority number closest to 0 becomes the primary device
(the default is 100).
After you create a VSD group, it must bind VSIs to the VSD group.
Virtual Security Interfaces (VSIs) are the virtual interfaces that two
security devices forming a virtual security device (VSD) share
when operating in High Availability (HA) mode:
Each VSI has its own IP address.
You must manually assign VSIs to VSDs for each security zone
configured on the security device.
The high availability schema adopted in Nokia's BSC site solution
foresees to use the two NetScreens in active/active configuration.
For this is needed to group the two NetScreen (e.g. NetScreen A
and NetScreen B) into:
Two VSD groups (e.g. VSD 0 and VSD 1) in case of no M-plane separation. NetScreen A is
primary device in VSD 0 and NetScreen B is primary device in VSD 1.
Three VSD groups (e.g. VSD 0, VSD 1 and VSD2) in case of M-plane separation. NetScreen
A is primary device in VSD 0and NetScreen B is primary device in VSD 1 and VSD2. See
also section 6.2.2.

DN0976647 © 2014 Nokia Networks 28 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

• High Availability (HA) interfaces.

All NSRP information (data link traffic and control traffic) passes
between cluster members through two dedicated HA links. A link
carries only Control traffic and the other one carries the data link
traffic. In case of failure of a dedicated HA link, the remaining one
will carry both data link and control traffic. It is possible to configure
up to 3 links (i.e. 2 dedicated HA links + 1 additional link being as
HA links, but only two of them are in operation (i.e. the third is a
standby link).
In Nokia site solution 2 dedicated 1GE HA links are recommended.
• Failure of active device.
• The IP address of VSI is a virtual IP address: i.e. the traffic
directed to this IP is processed by the active NetScreen device. In
case of failure of active NetScreen, this address is handled by the
stand-by NetScreen. The IP address and subnet of a VSI will be
the same as those configured on the underlying physical
interface’s pair (e.g. ethernet1 in NetScreen 0 and ethernet 1 in
NetScreen 1).

DN0976647 © 2014 Nokia Networks 29 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

Virtual Interface
Trusted zone
VSI1
VSD VSI2 BSC
ATS
group 0
SSM 1
Untrusted zone (*)

VSI1:1 VSD VSI2:1 PTP-M

group 1 TCSM

Virtual Devices

Physical Devices Trusted zone

VSI1 VSI2 BSC

ATS
SSM
2
(*)
Untrusted zone
VSI1:1 VSI2:1 PTP-M
TCSM

Physical Devices Trusted zone

BSC
3
ATS
SSM
(*)
Untrusted zone VSI1 VSI2
VSI1:1 VSI2:1 PTP-M
TCSM

Physical
Interfaces

Figure 5: VSD group & VSI (no M-plane separation)

DN0976647 © 2014 Nokia Networks 30 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

5.3.9 Management

There are different means available for managing Juniper NetScreen both
locally and/or remotely.

Following means of Management are available:

• Management with the Web User Interface (WebUI)
WebUI is a browser – based interface (Microsoft Internet Explorer
version 5.5 or later) for configuration of the NetScreen. It is
available over HTTP and HTTPS.
• Management with the Command Line Interface (CLI)
Advanced administrators can attain finer control by using the
command line interface (CLI). To configure a security device with
the CLI, you can use any software that emulates a VT100 terminal.
With a terminal emulator, you can configure the security device
using a console from any Windows, UNIX, or Macintosh operating
system. For remote administration through the CLI, you can use
Telnet or Secure Shell (SSH). With a direct connection through the
console port, you can use HyperTerminal.
• Management via Network and Security Manager (NSM)
Network and Security Manager (NSM) is Juniper Networks’
management software application that configures and monitors
multiple Juniper Networks’ security devices over a local area
network (LAN) or a wide area network (WAN) environment. The
NSM enables network administrators to deploy, configure, and
manage multiple devices from central locations.

The management traffic may be aggregated with the BSC traffic over
Backbone port (so called in-band management) or the dedicated Management
ports may be used.

Management module include following ports:

• An RJ-45 console port, for Local CLI sessions via serial terminal
emulation programs such as HyperTerminal.
• A modem port for Remote CLI sessions by dialing into it via V.92
Modem Port on NetScreen.
• A management port, for WebUI sessions or remote CLI sessions
via Telnet/SSH.

DN0976647 © 2014 Nokia Networks 31 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

Figure 6: Management module ports

5.3.9.1 Monitoring
NetScreen provides Log and Alarms to allow Operator to monitor the systems.
Main Log generated is the following:
• Event Log
ScreenOS provides an event log for monitoring system events
such as configuration changes, and self-generated messages and
alarms regarding operational behavior and attacks. The event log
displays the date, time, level and description of each system event.
It is possible to view system events for each category stored in
flash storage on the security device through the WebUI or the CLI.
To view the file it is possible to use an ASCII text editor (such as
Notepad or WordPad). Alternatively, it is possible also to send
such files to an external storage space.
• Traffic log
The Juniper Networks security device can monitor and record
traffic that it permits or denies based on previously configured
policies. You can view traffic log entries stored in flash storage on
the security device using either the WebUI or the CLI.
• Self Log
ScreenOS provides a self log to monitor and record all packets
terminated at the security device. For example, if you disable some
management options on an interface—such as WebUI, SNMP,
and ping—and HTTP, SNMP, or ICMP traffic is sent to that
interface, entries appear in the self log for each dropped packet.
You can view the self log, which is stored in flash storage on the
security device, through either the CLI or WebUI.

DN0976647 © 2014 Nokia Networks 32 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

• SysLog
A security device can generate syslog messages for system
events at predefined severity levels and, optionally, for traffic that
policies permit across a firewall. It sends these messages to up to
four designated syslog hosts running on UNIX and Linux systems.

The security device supports traffic alarms when traffic exceeds thresholds
that you have defined in policies. You can configure the security device to alert
you through one or more of the following methods whenever the security
device generates a traffic alarm e.g
• Console
• Internal (Event Log)
• Email
• SNMP
• Syslog

By means of Simple Network Management Protocol (SNMP) agent for the

Juniper Networks security device provides network administrators with a way
to view statistical data about the network and the devices on it and to receive
notification of system events of interest.

5.4 NetScreen Performances

5.4.1 NetScreen-5200

• Interfaces: Up to 8 GE interfaces (1 NetScreen-5000 8G2-G4

SPM module) or 2x10 GE (1 NetScreen-5000 2XGE-G4 SPM
module) + 1 5000-MGT3 management module.
• VLAN: Up to 4,094 VLANs
• VPN performance:
25,000 IPsec VPN tunnels
3 million pps VPN
Up to 5 Gbps 3DES VPN (2 Gbps for 64 byte packets)

DN0976647 © 2014 Nokia Networks 33 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION Juniper NetScreen Series

• Firewall performance:
Up to 10 Gbps FW (4 Gbps for 64 byte packets)
6 million pps FW
1 million concurrent sessions (e.g. ICMP/UDP/TCP sessions)

5.4.1.1 NetScreen-5400
• Interfaces: Up to 24 GE interfaces (3NetScreen-5000 8G2-G4
SPM modules ) or 6x10 GE (3 NetScreen-5000 2XGE-G4 SPM
modules) + 1 5000-MGT3 management module
• VLAN: Up to 4,094 VLANs
• VPN performance:
25,000 IPsec VPN tunnels
9 million pps VPN
15 Gbps 3DES and VPN (6 Gbps for 64 byte packets)
• Firewall performance:
Up to 30 Gbps FW (12 Gbps for 64 byte packets)
18 million pps FW
2 million concurrent sessions (e.g. ICMP/UDP/TCP sessions)

DN0976647 © 2014 Nokia Networks 34 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

6 BSC site solution: SGW Setup

The following chapters explain main steps to set up the Juniper NetScreen:
• Connecting the two NetScreen devices to Multilayer Switch ports
• Setting interfaces in Route Mode (i.e. NetScreen acts as L3
device)
• Setting parameters for active/active high availability:
configure two VSD groups
configure physical interfaces with IP address and subnet
bind them to security zones and to VSD group
• Configure the IP tracking parameters. IP tracking is used to trigger
the device failover (i.e. failover between redundant NetScreens).
• Configure OSPF parameters.
• Define site-to-site VPN.
• Define polices for firewall (also SCREEN function shall be
enabled)

Note:
Description in this section does not cover the exact
configuration order; the selected order is for readability
purpose

6.1 Installation
The physical layouts including NetScreen devices at the BSC site is depicted
in Figure 7:

DN0976647 © 2014 Nokia Networks 35 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

• Two redundant NetScreen devices are interconnected via two

dedicated High Availability GE interfaces.
• NS-0 is connected to MLS-0 via two separated interfaces.
Interface to the trust zone (green interface). This interface carries traffic from BSC, sync
devices to NS and vice versa.
Interface to the untrust zone (red interface). This interface carries traffic from transport
Network to NS and vice versa.
One single GE or 10 GE may be used. Multiple GE interfaces with link aggregation allows
coping with high traffic scenarios.
• The same shall be applied between NetScreen 1 and MLS 1.

Figure 7: SGW physical layout in BSC site solution with active/active

redundancy

1. Each physical interface will be configured in route-mode, i.e. it will

work at L3 layer.

DN0976647 © 2014 Nokia Networks 36 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

2. NetScreen shall interconnect two security zones (trust zone and

untrust zone). In the same NetScreen device 50% of physical
interfaces will be assigned to the trust zone; the remaining 50% to
the untrust zone.
3. In case of high throughput a 10 GE may be used or multiple
physical interfaces (owned by the same NetScreen device) and
related to the same security zone will be bundled by means of link
aggregation (see Figure 5). In alternative to link aggregation
separated L3 interfaces may be configured (see Figure 6).

Link Agrregation MLS-0

BSC
Backbone L3

NS0
1
SWU-2 SWU-0

active
PTP-M
HA links
ETP PCU CPU
NS1

ATS
active
2

SWU-3 SWU-1
Backhaul
Interface in Untrust zone

MLS-1
Interface in Trust zone

Figure 8: SGW physical layout in BSC site solution with active/active

redundancy with link aggregation

DN0976647 © 2014 Nokia Networks 37 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

MLS-0
BSC
Backbone L3

NS0
1
SWU-2 SWU-0
3
active
PTP-M
HA links
ETP PCU CPU
NS1

ATS
active 4
2

SWU-3 SWU-1
Backhaul
Interface in Untrust zone

MLS-1
Interface in Trust zone

Figure 9: SGW physical layout in BSC site solution with active/active

redundancy with separated L3 interfaces

6.2 SGW provisioning

6.2.1 General

6.2.1.1 Packet Abis VPN

Packet Abis usually refer to Abis C/M/U/S-plane, SSE, Synchronization traffic
even if SSE and S-plane are not terminated in BSC.

DN0976647 © 2014 Nokia Networks 38 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

From BTS point of view there is one IPsec Security Association (IPsec SA) for
each plane. This means maximum 14 unidirectional IPsec SA per BTS given
by:
• 2 (C-plane)
• 2 (U-Plane-CS)
• 2 (Packet Delay Measurement)
• 2 (U-Plane-PS)
• 2 (M-Plane)
• 2 (Site Support Equipment)
• 2 (Timing over Packet)

It is possible to enable/disable IPsec separately over C-plane, U-plane CS (1),

U-plane PS, M-plane, S-plane (PTP 1588), SSE.

Security measures in case of IPsec are enabled for a specific plane is

summarized in Table 4.

Table 4: Packet Abis Security measures

Plane \ IPsec security Encryption Authentication Integrity

measure
C-plane traffic No Yes Yes
U-plane CS traffic Yes-Optional Yes Yes
Packet Delay Measurement Yes-Optional Yes Yes
(PDM) (1)
U-plane PS traffic No (U-plane PS is already Yes Yes
encrypted at application layer).
M-plane traffic Yes-Optional Yes Yes
Site Support Equipment Yes-Optional Yes Yes
traffic
S-plane ( PTP 1588) traffic No Yes Yes
S-plane (Dummy PWE for No No No
Adaptive clock recovery)
traffic

Notes:
1. At BTS-side, the security association related to Packet Delay
Measurement (PDM) traffic is automatically enabled/disabled as

DN0976647 © 2014 Nokia Networks 39 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

consequence of enabling/disabling of the security association

related to U-plane CS traffic.
The security measures applied to Packet Delay Measurement
(PDM) traffic (i.e. authentication/integrity, encryption, encryption
algorithm) are the same as those applied to U-plane CS traffic.
IPsec is used in tunnel mode (Figure 10):
• In the most simple case (Figure 10 label A):
− All IPsec SAs use one single pair of outer IP
addresses.
− From SGW point of view it is not necessary to use a
different outer IP address per BTS. SGW does not
have the “BTS concept”.
• In case of M-plane separation (Figure 10 label B1 and B2):
− A first pair of outer IP addresses is used for M-plane.
− A second pair of outer IP addresses is used for C/U/S-
plane and PDM IPsec SAs.
− SSE IPsec SA in alternative may use first pair (Label
B1) or second outer IP addresses pair (Label B2).
− SGW uses two outer IP addresses for all connected
BTSs.
• Maximum three outer IP addresses pair may be defined (Figure
10 label C):
− A first dedicate pair of outer IP addresses is used for
M-plane IPsec SA.
− A second pair of outer IP addresses is used for C/U/S-
plane and PDM IPsec SAs.
− A third pair is used to for SSE SA.
The third tunnel may be created in principle in the same SGW
terminating also other planes, but this third tunnel is mainly defined
in case SSE traffic is directed towards a site different from the BSC
site (Figure 10 label D). In this case the external security gateway
at BSC does not handle this kind of Security Associations (SAs).

DN0976647 © 2014 Nokia Networks 40 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

BTS A

a.b.50.1
SGW
VPN tunnel
Max 7 vpn per BTS

a.b.4.2
BTS

a.b.50.2
BSC Site

BTS BTS
B1 a.b.50.1
B2
a.b.50.1
SGW SGW
a.b.60.1 a.b.60.1
a.b.4.2 a.b.4.2
BTS
BTS a.b.4.5
a.b.4.5
a.b.50.2 a.b.50.1
BSC Site BSC Site
a.b.60.2 a.b.60.1

BTS
SGW
C D
a.b.50.1 a.b.80.1
a.b.50.1

a.b.60.1 SGW NetAct Site

a.b.60.1
a.b.70.1 a.b.4.2
a.b.70.1 a.b.4.2
BTS
a.b.4.5 BTS
a.b.4.5
a.b.50.2 a.b.4.7 a.b.50.2

BSC Site SGW

a.b.60.2 a.b.60.2
a.b.70.2
a.b.70.2
Possible, but Teoretical case BSC Site

Figure 10: Packet Abis vpn (outer IP endpoints)

6.2.1.2 AoIP, SIGTRAN, Packet Ater and ETPSIG VPN

In case of IPsec is used also over AoIP, SIGTRAN, Packet Ater and external
ETPSIG, two different outer IP endpoints are defined at SGW side as in Figure
11. Worth noting that packet Ater is in alternative to AoIp and applicable only
in case of U- plane traffic between mcBSC and mcTC when mcTC is located
remotely with respect to the mcBSC site.

DN0976647 © 2014 Nokia Networks 41 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Figure 11: Packet Abis, AoIP/ETPSIG and SIGTRAN vpn (with active/active
SGW configuration)

DN0976647 © 2014 Nokia Networks 42 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

In case of M-plane separation an additional IP endpoints has to be provisioned

because BTS requires having two separated remote IP endpoints in case of
M-plane separation.

Figure 12: Packet Abis, AoIP/ETPSIG and SIGTRAN vpn (with m-plane
separation and active/active SGW configuration)

DN0976647 © 2014 Nokia Networks 43 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

6.2.2 HA provisioning

HA provisioning is summarized as following:

1. The NSRP cluster shall be created composed by the two
NetScreen.
2. The active/active redundancy schema is recommended;
3. Traffic is divided into different groups VSD. In each single group,
one of the devices is defined as primary (i.e. it processes the traffic
within the group) and the other one as secondary (i.e. it does not
process any traffic until the primary device goes out of service).
After you create a VSD group, it must bind VSIs to the VSD group.
You must manually assign VSIs to VSDs for each security zone
configured on the security device.
4. Two NetScreen devices are assigned to VSD groups .
In each single group, one of the devices is defined as primary (i.e.
it processes the traffic within the group) and the other one as
secondary (i.e. it does not process any traffic until the primary
device goes out of service). The role of primary/secondary
NetScreen device inside a VSD group is assigned by means of a
priority value. The device with the priority number closest to 0
becomes the primary device (the default is 100).
5. The IP tracking shall be used to trigger the failover between
NetScreen devices. NetScreen 0 shall monitor IP addresses of
MLS 0 and the same should do NetScreen 1 with respect to MLS1.
6. Links are plugged on dedicated port for HA.

With reference to outer IP endpoints provisioning as summarized in Figure 11

and Figure 12 two examples of HA provisioning are included in the next
figures and tables.

Also Packet Abis U-plane is depicted on the picture to show how the traffic
goes through the SGW.

DN0976647 © 2014 Nokia Networks 44 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

BSC Site
MLS-0 BSC
SWU-0

SWU-2

active

SGW-0

a.b.4.1 U-00 U-00

T-00 T-00
a.b.5.1

a.b.50.1 ETP

Device failover
triggered

HA Link
by IP tracking

a.b.5.2 U-00
T-00
U-00 T-00
a.b.4.2
SGW-1
a.b.50.2
active

SWU-1

SWU-3
MLS1

Figure 13: HA configuration overview example (without m-plane

separation)

Table 5: NSRP configuration (without m-plane separation)

Group ID Usage VSI ID and IP GSW Priority

value
0 O&M/CBC, VSI_U0 (a.b.4.1) SGW-0 10
SIGTRAN-1,
VSI_T0 (a.b.5.1) SGW-1 90
PWE Ater, AoIP,
Packet Ater
1 GboIP, VSI_U1 (a.b.4.2) SGW-0 90

DN0976647 © 2014 Nokia Solutions and Networks 45 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

ETPSIG, VSI_T1 (a.b.5.2) SGW-1 10

SIGTRAN-2,
PWE Abis,
PAoEth

BSC Site
MLS-0 BSC
SWU-0

SWU-2

active

SGW-0

a.b.4.1 U-00 U-00

T-00 T-00
a.b.5.1

a.b.50.1 ETP

Device failover
a.b.60.1 triggered
HA Link

by IP tracking

a.b.5.5

a.b.5.2
T-00 U-00
U-00 T-00
a.b.4.2
SGW-1
a.b.50.2
a.b.4.5
active
a.b.60.2

SWU-1

SWU-3
MLS1

Figure 14: HA configuration overview example (with M-plane separation)

DN0976647 © 2014 Nokia Solutions and Networks 46 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Table 6: NSRP configuration (with M–plane)

Group ID Usage VSI IP GSW Priority

value
0 O&M/CBC, SIGTRAN- VSI_U0 (a.b.4.1) SGW-0 10
1,
VSI_T0 (a.b.5.1) SGW-1 90
PWE Ater, AoIP,
Packet Ater
1 GboIP, VSI_U1 (a.b.4.2) SGW-0 90
ETPSIG, VSI_T1 (a.b.5.2) SGW-1 10
SIGTRAN-2,
PWE Abis,
PAoEth C/U/S-plane

2 PAoEth M-plane VSI_U2 (a.b.4.5) SGW-0 90

VSI_T2 (a.b.5.5) SGW-1 10

6.2.3 Routing table provisioning

NetScreen device provides two pre-defined virtual routers:

• trust virtual router (trust-vr)
• untrust virtual router (untrust-vr)
Each virtual router sees the other one as next-hop router when forwarding of
inter-zone traffic is needed.
Each virtual router automatically will incorporate in routing table all the directly
connected subnets: i.e. the subnets of VSIs.

6.2.4 OSPF provisioning

Configuration of OSPF is needed to automatically exchange route’s

information among neighbouring routers.

DN0976647 © 2014 Nokia Networks 47 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

6.2.5 VPN provisioning

NetScreen’s security policy basic concept

NetScreen secures a network by inspecting, and then allowing or denying, all
connection attempts that require passage from one security zone to another.
By default, a security device denies all traffic in all directions. Through the
creation of policies, you can control the traffic flow from zone to zone (or also
traffic between interfaces in the same zone) by defining the kinds of traffic
permitted to pass from specified sources to specified destinations.

The following kind of policies shall be configured:

• Interzone policies. These policies regulate the traffic between Trust
and Untrust zones. Each policy defines the direction where it is
applied: in case a policy is defined from trust to untrust zone, then
it will be applied to traffic flows exiting from trust zone and willing to
enter into the untrust zone.

The basic policy elements are selectors and action.

Selectors are the following:
• Direction: The direction of traffic between two security zones (from
a source zone to a destination zone);
• Source /destination address: The address from/to which traffic
initiates/terminates;
• Service: the type of traffic transmitted, defined by transport
protocol (TCP/UDP/ICMP etc), Source and destination port
numbers.

When security device receives traffic matching the rule, it executes one of
following actions: deny, permit, reject, or tunnel;
• Deny blocks the packet from traversing the firewall.
• Permit allows the packet to pass the firewall.
• Reject blocks the packet from traversing the firewall. The security
device drops the packet and sends a TCP reset (RST) segment to
the source host for TCP traffic and an ICMP “destination
unreachable, port unreachable” message (type 3, code3) for UDP
traffic. For types of traffic other than TCP and UDP, the security
device drops the packet without notifying the source host, which is
also what occurs when the action is “deny.”
• Tunnel: the traffic subject to IPsec processing.

DN0976647 © 2014 Nokia Networks 48 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Policies, in general, are used to setup VPN tunnels and to define firewall rules.
Examples in the next sections.

NetScreen’s VPN configuration methods: route-based and policy – based

VPN

NetScreen allows the configuration of IPsec VPNs with two basic methods: the
route-based VPNs and the policy-based VPNs.
With policy-based VPN method, the IPsec SAs are defined at policy level, i.e.
• A policy, having action=tunnel, identifies an IPsec SA.
• The traffic that matches with the traffic selectors indicated in the
policy will be protected by IPsec.

With route-based VPN method

• In NetScreen it shall be defined a tunnel interface per IPsec SA.
The tunnel interface is a logical interface representing an IPsec
SA.
• Routing a traffic flow through a tunnel interface implies that this
traffic will be protected by IPsec. Before being routed, the traffic
can be filtered by one or more policies. In route-based VPN the
policies will provide action=permit or deny.
• In NetScreen’s routing table shall be indicated the BTS inner IP
endpoints that can be reached through the tunnel interface: the
traffic that is routed through the tunnel interface will be protected
by IPsec.

In principle both methods are equivalents. However the traffic selectors,

exchanged via IKE messages, may differ in the two methods. Therefore
interoperability limitations, between NetScreen and the remote peer’s IPsec
implementation, could be solved by using one of them. See section 6.2.6.1 for
interoperability issues in Packet Abis interface. See section 6.2.7 for
examples.

6.2.6 Packet Abis VPN provisioning

Figure 15 shows an example of the relationships among Packet Abis traffic

flows, inner IP endpoints and IPsec security associations.

DN0976647 © 2014 Nokia Networks 49 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Figure 15: Packet Abis relationships among traffic flows, IP endpoints and
IPsec security associations

Relationship between inner IP endpoints and outer IP endpoints is

summarized in Figure 16.

• Label A. There is not M-plane separation neither at outer level nor

at inner level. One single inner IP endpoint is used at BTS side for
M/C/U/S-plane and PDM.
In BSC, TRXSIG messages towards on single BTS may be
originated by more than one IP address. OMUSIG message may
use an IP address common to one of C-plane addresses.
• Label B1. There is M-plane separation. Two outer IP addresses
are configured at BTS side. Two inner IP endpoint are used at
BTS side.
SSE uses the same outer IP endpoints used by M-plane.
In BSC, TRXSIG messages towards on single BTS may be

DN0976647 © 2014 Nokia Networks 50 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

originated by more than one IP address. OMUSIG messages have

its dedicated IP address.
• Label B2. Same as B1, but SSE use the same outer IP endpoints
used by C/U/S-plane and PDM.
Label C. SSE traffic use a dedicated pair of outer IP endpoints.

A BTS SGW BSC

M-plane

C-plane
CS U-plane
PS U-plane
PDM
VPN tunnel (i.e. “IPSEC SA bidiectional”)
S-plane
SSE PTP-M
SSE IKE SA negotiates
SSE-M multiple child IPSEC SA

SSE BTS SGW SSE-M B2 BTS SGW BSC

SSE M-plane

M-plane C-plane
BSC CS U-plane
C-plane
PS U-plane
CS U-plane PDM
PS U-plane S-plane
PDM SSE PTP-M
B1 S-plane
PTP-M
SSE
SSE-M

C BTS SGW BSC

M-plane Remote BTS inner IP addresses
C-plane Local SGW inner IP endpoints
CS U-plane
PS U-plane Remote BTS outer endpoints
PDM
S-plane Local SGW outer endpoints
SSE PTP-M
SSE
SSE-M

Figure 16: Traffic type, SA, inner/outer IP endpoints relationship

6.2.6.1 Configuration hints for Packet Abis security associations

In order to configure the security associations for Packet Abis traffic, the
following hints shall be taken into account.

DN0976647 © 2014 Nokia Networks 51 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Table 7: Hints to configure the security associations for Packet Abis traffic

Packet Abis SA SA traffic selectors BTS/SGW behavior Suggested configuration

definition: method (policy-based or
route-based)
-M-plane SA, Single IP and single BTS sends via IKE the Route-based or policy-
port IP address and port; based VPNs
-PS U-plane SA
NetScreen (with
-CS U-plane SA
policy-based VPN)
-PDM SA sends, via IKE, IP
address and single
port;
NetScreen (with route-
based VPN) sends, via
IKE, IP address and
single port.
-C-plane SA List of IPs (each one Policies (list of IPs and Route-based VPN or
associated with a related ports) are policy-based VPN
specific port) installed in BTS.
Note:
BTS sends, via IKE,
if policy – based is used
the list of IP
then the policies shall
addresses, with port
contain port selector=”any”
selector = “any”.
, otherwise IKE negotiation
If in NetScreen (with with BTS will fail.
route-based VPN) are
This, however, implies that
configured policies
NetScreen does not check
that provide list of IPs
the destination ports for
and related ports, then
the traffic towards BTS
NetScreen will send,
(the traffic from all the
via IKE, only one IP
ports will land on BTS for
address and
that IPs).
port=”any”.
This means that IKE
negotiation with BTS
will succeed.
If in NetScreen (with
policy-based VPN),
are configured policies
that provide list of IPs
and port = “any” then
NetScreen will send,
via IKE, list of IP
addresses with port
selectors=”any”.
This means that IKE
negotiation with BTS

DN0976647 © 2014 Nokia Networks 52 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

will succeed.
If in NetScreen (with
policy-based VPN) are
configured policies
that provide list of IPs
and related ports, then
NetScreen will send,
via IKE, the list of IP
addresses and ports.
This means that IKE
negotiation with BTS
will fail.
-SSE List of IPs (because Policies, containing a Route-based or policy-
there may be more list of IPs, are installed based VPNs
than one SSE at BTS both in BTS and SGW.
side). Port selector is
BTS sends, via IKE,
“any”.
list of IPs with port
selector=“any”.
NetScreen (policy-
based VPN) sends, via
IKE, list of IPs with
port selector=“any”.
NetScreen (route-
based) sends only one
IP address and
port=ANY.
In both cases above
the IKE negotiation
succeeds.
-PTP Single IP, port is any BTS sends via IKE the Route-based or policy-
IP address and port based VPNs
selector=”any”;
NetScreen (policy-
based VPN) sends IP
address and and port
selector=”any”.
NetScreen (route-
based VPN) sends IP
address and and port
selector=”any”.
In both cases above
the IKE negotiation
succeeds.

DN0976647 © 2014 Nokia Networks 53 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

6.2.6.2 IKE provisioning

Following parameters have to be configured:
• IKE main mode;
• Encryption algorithm: AES in CBC mode with 128-bit key length.
• Pseudo-random function: HMAC-SHA1.
• Integrity: HMAC-SHA1-96.
• Diffie-Hellman group: 2 (1024-bit MODP)
• Time based lifetime: 24 hours.
• Authentications method: X.509 certificates (PKI).
• Certificate Type: RSA
• Bit Length: 2048
• Anti-Replay Checking: no

Note: Re-keying of IKE SAs shall be proactive i.e. the new IKE SA shall be
established before the old one expires and becomes unusable.

6.2.6.3 IPsec profile provisioning

Following parameters for IPsec have to be configured:
• IPsec Diffie-Hellman Group: 1 or 2 or 5 or 14 (used only if PFS is
used).
• IPsec Protocol: ESP
• Mode: Tunnel
• Encryption algorithm (configurable, depending on the traffic plane):
AES in CBC mode with 128-bit key length.
Null encryption.
• Pseudo-random function: HMAC-SHA1.
• Integrity: HMAC-SHA1-96.
• Re-keying of IPsec SAs shall be proactive i.e. the new IPsec SA
shall be established before the old one expires and becomes
unusable.
• Time based lifetime (phase 2 SA lifetime): 24 hours

DN0976647 © 2014 Nokia Networks 54 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

6.2.7 Example of VPN provisioning

Note:
Operator hint for configuration of IPsec for Packet
Abis:
Change of tunnel IP endpoint at SGW should not happen
before the new security gateway’s IP tunnel endpoint has
been configured within BTS.

Note:
Depending on the SGW SW version, the following
issue may occur:
Juniper does not send alarm when IPsec SA mismatch
occurs during phase 2 proposal in IKE_AUTH. Operator is
not informed that IPsec SAs are not established.

If the SGW SW version available contains a previous

bug:
Operator will not get alarm on BTS. But operator can
check the event logs at Juniper to see if the SA is
correctly established or reason for failure.

DN0976647 © 2014 Nokia Networks 55 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Note:
Depending on the SGW SW version, the following issue may
occur:
When parameters related to SA configuration (for example, encryption
algorithm) are changed, SA has to be re-established. Both BTS and
SGW initiate CHILD_SA procedure. During this procedure continuous
traffic is received from BSC, for that reasons Juniper is not able to
close the procedure and then it does not activate CHILD SA. This
means that traffic can not be protected by IPsec and it is not
transmitted to BTS.
Use Juniper release 6.3.0r4-cu3.0, as it contains the fix for issue
mentioned above.
If this version of Juniper is not available, use the following work-
around:
• Block the traffic at Juniper. This means disabling the policies at Juniper before any SA
configuration change at BTS. Policies of both trust to untrust and untrust to trust for
the respective SA have to be blocked.
• After SA re-establishment, enable the policies again and the traffic for the
corresponding planes start flowing again.
• Make the configuration changes using the element manager in Local mode (not
Remote mode).
Disabling/enabling policies is a check box near the policy that is used for
traffic based SA triggering:
• If policy is enabled, then depending on the policy the traffic is either protected or not
protected.
• If policy is disabled, then as no rules are found for traffic, the traffic is blocked.
Traffic is required to be blocked for only those planes (SA) whose configuration is to be
changed. If configuration change affects all planes, then all traffic should be blocked.

DN0976647 © 2014 Nokia Networks 56 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Note:
There is one issue when all following conditions are satisfied:
• IPsec is enabled both for C-plane and M-plane.
• One single IP address in BTS for M/C/U/ToP-plane.
• BSC M-plane and BSC C-plane IP addresses are the same.
I.e. following kinds of configuration is not accepted in Juniper NetScreen.
Selectors
Traffic Inner BSC Inner BTS Protocol BSC port BTS port Action Outer Outer Dest
flow IP IP Source IP IP
M-plane BSC- BTS- UDP BSC U_PS BTS U_PS tunnel ** **
SA MC@ MCUS@ port port
C-plane UDP any any tunnel ** **
SA

BTS allows configuring only “any” and “single port”.

Juniper NetScreen SGW does not accept previous configurations i.e. does not allow configuring “any” for U-
plane_CS since M-plane and C-plane IP addresses at BSC site are the same. Juniper NetScreen considers
M-plane policy a subset of C-plane policy.
Selectors are configured both in BTS and SGW and they have to be consistent. Selectors are sent also on the
IKE messages. It is not possible disable this exchange/check.
BSC M-plane and BSC C-plane IP addresses have to be different. This is the recommended configuration:
Selectors
Traffic flow Inner Inner Protocol BSC port BTS port Action Outer Outer
BSC IP BTS IP Source IP Dest IP
M-plane SA BSC-M@ BTS- UDP BSC U_PS BTS U_PS tunnel ** **
MCUS@ port port
C-plane SA BSC-C@ UDP any any tunnel ** **

DN0976647 © 2014 Nokia Networks 57 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Alternatively also BTS IP addresses can be different:

Selectors
Traffic Inner Inner Protocol BSC BTS Action Outer Outer
flow BSC BTS IP port port Source Dest
IP IP IP
M- BSC- BTS- UDP BSC BTS tunnel ** **
plane MC@ M@ U_PS U_PS
SA port port
C- BTS- UDP any any tunnel ** **
plane CUS@
SA

DN0976647 © 2014 Nokia Networks 58 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Note:
When M-plane is configured in probe mode, if an
IPsec - protected M-plane cannot be established, BTS
will try to establish a not IPsec -protected M-plane
towards BSC. However NetScreen has in its database
a policy that allows only encrypted M-plane.
For this, not-encrypted M-plane will be dropped by
NetScreen.

If this issue occurs, manual intervention is needed for

modifying M-plane policy in NetScreen. This operator's
intervention would be triggered by alarm raised by
NetScreen, in case there are some problems when trying
to establish IPsec connections with BTS.

In that way Operator may reach BTS via EM and modify

BTS parameters if the reason of SA failure was a
parameter mismatch or a BTS SW issue. On the contrary
a BTS site intervention is needed.

As soon as investigations are completed, M-plane policy

in NetScreen has to be restored.

DN0976647 © 2014 Nokia Networks 59 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Note:
NetScreen's rekeying feature requires also the activation
of VPN monitoring feature in NetScreen. VPN monitoring
feature makes use of ICMP messages that are sent over
each monitored VPN, however VPN solution in BTS
doesn’t allow ICMP traffic to pass through VPNs. For this
reason the VPN monitoring and the rekeying features
don’t work when NetScreen interoperates with BTS.
Therefore it is recommended that operator does not
enable VPN monitoring and rekeying features. Instead
responsibility of IKE SA rekeying and CHILD SA rekeying
lies with BTS alone. Operator should take care, during
configuration, that lifetime of IKE SA and CHILD SAs
configured at BTS are less than that configured at
NetScreen.

DN0976647 © 2014 Nokia Networks 60 / 78

Issue 01C
 BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Table 8: SGW policy-based VPN configuration: example (Use Case B1) for Packet Abis interface

Traffic Direction Inner Source Inner protocol Source port Destination Action VPN tunnel Outer Outer Security
flow IP Destination port Source Destinat measures
(source (IPsec bi-
IP IP ion IP
zone directional
destinatio SA)
n zone)
Site Trust SSE_manager SSE@ any any any tunnel SSE_SA VSI_U2 BTS@1 Encryption(
Support untrust @ @ optional)+a
traffic uth.
M- Trust BSC-M@ BTS-M@ SCTP M-plane port M-plane port tunnel M-plane SA Encryption(
Plane untrust optional)+a
uth.
C-Plane Trust BSC-C@1 BTS-CUS@ SCTP any any tunnel C-plane SA VSI_U1 BTS@2 authenticati
untrust @ on
BSC-C@2 any any
BSC-C@3 any any
U-Plane Trust BSC-U@ UDP U_CS- port U_CS- port tunnel U-plane_CS Encryption(
CS untrust plane SA optional)+a
uth.
PDM Trust UDP PDM port PDM port tunnel PDM SA Encryption(
untrust optional)+a
uth.
U-Plane Trust UDP U_PS- port U_PS- port tunnel U-plane_PS authenticati
PS untrust SA on
Top Trust PTP-M@ UDP any any tunnel S-plane SA authenticati
PTP untrust on
(IEEE
1588v2)

DN0976647 © 2014 Nokia Networks 61 / 78

Issue 01C
 BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Table 9: SGW policy-based VPN configuration: example (Use Case B1) for Packet Abis interface (continued)

Traffic Direction Inner Inner protoc Source Destination Action VPN tunnel Outer Outer Security
flow Source IP Destination ol port port Source Destinati measures
(source (IPsec bi-
IP IP on IP
zone directional SA)
destination
zone)
Site Untrust SSE@ SSE_M@ any any any tunnel SSE_SA BTS@1 VSI_U2@ Encryption(opt
Support trust ional)+auth.
traffic
M-Plane Untrust BTS-M@ BSC-M@ SCTP M-plane M-plane port tunnel M-plane SA Encryption(opt
trust port ional)+auth.
C-Plane Untrust BTS- BSC-C@1 SCTP any any tunnel C-plane SA BTS@2 VSI_U1@ authentication
trust CUS@
BSC-C@2 any any
BSC-C@3 any any
U-Plane Untrust BSC-U@ UDP U_CS- port U_CS- port tunnel U-plane_CS SA Encryption(opt
CS trust ional)+auth.
PDM Untrust UDP PDM port PDM port tunnel PDM SA Encryption(opt
trust ional)+auth.
U-Plane Untrust UDP U_PS- port U_PS- port tunnel U-plane_PS SA authentication
PS trust
Top PTP Untrust PTP-M@ UDP any any tunnel S-plane SA authentication
(IEEE trust
1588v2)

DN0976647 © 2014 Nokia Networks 62 / 78

Issue 01C
 BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Table 10: SGW route-based VPN configuration: example (Use Case B1) for Packet Abis interface

Traffic Direction Inner Inner protocol Source port Destination Action VPN tunnel Outer Outer Security
flow Source IP Destinati port Source IP Destina measures
(source (IPsec bi-
on IP tion IP
zone directional
destination SA)
zone)
Site Trust untrust SSE_man SSE@ any any any permit SSE_SA VSI_U2@ BTS@1 Encryption(o
Support ager@ ptional)+auth.
traffic
M-Plane Trust untrust BSC-M@ BTS-M@ SCTP M-plane port M-plane port permit M-plane SA Encryption(o
ptional)+auth.
C-Plane Trust untrust BSC-C@1 BTS- SCTP C-plane port1 C-plane permit C-plane SA VSI_U1@ BTS@2 authenticatio
CUS@ port1 n
BSC-C@2 C-plane port2 C-plane
port2
BSC-C@3 C-plane port3 C-plane
port3
U-Plane Trust untrust BSC-U@ UDP U_CS- port U_CS- port permit U-plane_CS Encryption(o
CS plane SA ptional)+auth.
PDM Trust untrust UDP PDM port PDM port permit PDM SA Encryption(o
ptional)+auth.
U-Plane Trust untrust UDP U_PS- port U_PS- port permit U-plane_PS authenticatio
PS SA n
Top PTP Trust untrust PTP-M@ UDP any any permit S-plane SA authenticatio
(IEEE n
1588v2)

DN0976647 © 2014 Nokia Networks 63 / 78

Issue 01C
 BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Table 11: SGW route-based VPN configuration: example (Use Case B1) for Packet Abis interface (continued)

Traffic Directio Inner Source Inner protocol Source Destination Action VPN tunnel Outer Outer Security
flow n IP Destination port port Source Destinati measures
(IPsec bi-
IP IP on IP
(source directional
zone SA)
destinat
ion
zone)
Site Untrust SSE@ SSE_M@ any any any permit SSE_SA BTS@1 VSI_U2@ Encryption(opt
Support trust ional)+auth.
traffic
M-Plane Untrust BTS-M@ BSC-M@ SCTP M-plane M-plane port permit M-plane SA Encryption(opt
trust port ional)+auth.
C-Plane Untrust BTS-CUS@ BSC-C@1 SCTP C-plane C-plane port permit C-plane SA BTS@2 VSI_U1@ authentication
trust port 1 1
BSC-C@2 C-plane C-plane
port2 port2
BSC-C@3 C-plane C-plane
port3 port3
U-Plane Untrust BSC-U@ UDP U_CS- port U_CS- port permit U-plane_CS Encryption(opt
CS trust SA ional)+auth.
PDM Untrust UDP PDM port PDM port permit PDM SA Encryption(opt
trust ional)+auth.
U-Plane Untrust UDP U_PS port U_PS- port permit U-plane_PS authentication
PS trust SA
Top PTP Untrust PTP-M@ UDP any any permit S-plane SA authentication
(1588v2) trust

DN0976647 © 2014 Nokia Networks 64 / 78

Issue 01C
 BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Table 12: SGW policy-based VPN configuration example for AoIP, external ETPSIG, SIGTRAN interface

Traffic flow Direction(s Inner source Inner protoco Sourc Destinati action VPN Outer Outer Security
ource IP destinatio l e port on port tunnel source IP destinatio measure
zone n IP (IPsec bi- n IP s
destination directional
zone) SA)
AoIP trust ETPA subnet Remote any any any tunnel AoIP SA VSI_U0 @) Remote auth.+
untrust AovIP SGW IP@ encrypt.
subnet
Sigtran-1 trust Sigtran1 Remote any any any tunnel Sigtran1 Remote auth.+
(A,VNP,Lb ) untrust Subnet Sigtran SA SGW IP@ encrypt.
subnet
Packet Ater trust Packet Ater Remote any any any tunnel Packet Ater Remote auth.+
untrust subnet Packet SA Packet Ater encrypt.
Ater IP@
subnet
Sigtran-2 trust Sigtran2 Remote any any any tunnel Sigtran2 VSI_U1 @) Remote auth.+
A,VNP,Lb untrust subnet Sigtran SA SGW IP@ encrypt.
subnet
External trust ETPSIG Remote any any any tunnel ETPSIG Remote auth.+
untrust subnet ETPSIG SA SGW IP@ encrypt.
ETPSIG
subnet
AoIP untrust Remote AovIP ETPA any any any tunnel AoIP SA Remote VSI_U0 @) auth.+
trust subnet subnet SGW IP@ encrypt.
Sigtran-1 untrust Remote Sigtran1 any any any tunnel Sigtran1 Remote auth.+
(A,VNP,Lb) untrust Sigtran subnet Subnet SA SGW IP@ encrypt.
Packet Ater untrust Remote Packet any any any tunnel Packet Ater Remote auth.+
trust Packet Ater Ater SA Packet Ater encrypt.
subnet subnet IP@
Sigtran-2 untrust Sigtran2 Remote any any any tunnel Sigtran2 Remote VSI_U1 @) auth.+
DN0976647 © 2014 Nokia Networks 65 / 78
Issue 01C
 BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

(A,VNP,Lb) untrust subnet Sigtran SA SGW IP@ encrypt.

subnet
External untrust Remote ETPSIG any any any tunnel ETPSIG Remote auth.+
untrust ETPSIG subnet SA SGW IP@ encrypt.
ETPSIG
subnet

Table 13: SGW policy-based VPN configuration example for SIGTRAN-BBI interface

Traffic Direction Inner Inner destination protocol Source Destination action VPN Outer Outer Security
flow source IP IP port port tunnel source IP destination measures
(source
IP
zone (IPsec bi-
destination directional
zone) SA)
Sigtran-1 trust Sigtran1 Remote Sigtran any any any tunnel BBI-1 SA VSI_U0 Remote auth.+
(BBI) untrust Subnet subnet @) SGW encrypt.
IP@1
Sigtran-2 trust Sigtran2 Remote Sigtran any any any tunnel BBI-2 SA VSI_U1@) Remote auth.+
(BBI) untrust subnet subnet SGW encrypt.
IP@2
Sigtran-1 untrust Remote Sigtran1 subnet any any any tunnel BBI-1 SA Remote VSI_U0 @) auth.+
(BBI) trust Sigtran SGW encrypt.
subnet IP@1
Sigtran-2 untrust Remote Sigtran2 subnet any any any tunnel BBI-2 SA Remote VSI_U1 @) auth.+
(BBI) trust Sigtran SGW encrypt.
subnet IP@2

DN0976647 © 2014 Nokia Networks 66 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

6.3 Firewall provisioning

All traffic towards BSC Site is processed by SGW Firewall (both if it has to be
protected by IPsec or not). There may be some traffic going through MLS, but
not terminated in BSC Site as e.g. CMP, LDAP and SSE if SSE-M is in NetAct
Site. In this last case traffic is not managed by Firewall SGW.

CMP, LDAP

NETACT site

NetAct CA/
CR SSE-M

BSC

DCN /BackBone Network

ATS

Backhaul Network PTP-M

BSC Site

SSE traffic

Figure 17: Traffic not managed by Firewall

DN0976647 © 2014 Nokia Networks 67 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

6.3.1 Basic filtering rules

Policies shall be configured in order to allow traffic coming from untrust zone
to the trust zone.
The NetScreen’s security policy basic concept is described in section 6.2.5.
The policy contains the source and destination zones, source and destination
addresses, one or more services, and an action (permit, deny, reject, tunnel).

The rules to be configured concern the policies for the traffic flows allowed
(protected and not). These rules are indicated within the table below. Traffic
not indicated in this table is considered protected by IPsec see section 6.2.7.

DN0976647 © 2014 Nokia Networks 68 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Table 14: Filtering rules

protocol Source Destination Source Destination Source port Destination Action Notes
zone zone address address port
UDP(dummy untrust trust BTS IP of PWE IP of PWE BTS UDP port Port of PWE permit
PWE Abis) tunnel external for PWE external
equipment) equipment
UDP (PWE untrust trust BTS IP of PWE IP of BSC ETIP BTS UDP port BSC ETIP UDP permit
Abis) tunnel for PWE port

UDP(PWE untrust trust IP of TCSM IP of BSC ETIP UDP port of BSC ETIP UDP permit
Ater) ETIP TCSM ETIP port

UDP(PWE A) untrust trust IP of PWE of IP of TCSM UDP port of UDP port of permit
external ETIP external TCSM ETIP
equipment in equipment in
front of Media front of Media
gateway’s gateway’s

ESP untrust trust Security OMU IP Not applicable Not applicable permit This rule
gateway IP at address allows
(O&M/ CBC)
NetAct site O&M/CBC
traffic
ESP--
protected
coming
from
NetAct
site.

DN0976647 © 2014 Nokia Setworks 69 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

UDP untrust trust addresses of BSC/ TCSM, any For traceroutes permit
BTS or Core ATS,PTP-M towards BSC
(UDP – based
Network that pingable the port range
traceroute)
may send addresses is 33434 -
pings. 33533

ICMP untrust trust addresses of BSC/ TCSM, Not applicable Not applicable permit
BTS or Core ATS,PTP-M
Network that pingable
may send addresses
pings.
(O&M untrust trust Synchronization Synchronization Synchronization Synchronization permit
protocols for equipment’s equipment’s IP equipment’s equipment
synchronization manager IP address Manager port(s) port(s)
equipments) address
UDP (Gb over untrust trust SGSN IP BCSU IP Port range Gb Port range Gb permit
IP) address address over IP over IP

any trust untrust any any any any permit All traffic
exiting
from BSC
is allowed
by
firewall.

DN0976647 © 2014 Nokia Networks 70 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

6.3.2 Additional defence mechanisms

NetScreen provides a long list of additional defence mechanisms as described

in /4/.
A partial list of main mechanisms is provided here:
1. Reconnaissance deterrence
• IP address sweep
• Port scanning
• TCP/UDP Sweep Protection
• Operating system probes
• Evasion techniques
2. Denial of service (DoS) attack defenses
• Firewall DoS attacks
Session table flood
SYN-ACK-ACK proxy flood
• Network DoS attacks
SYN flood
ICMP flood
UDP flood
• OS-specific DoS attacks
Ping of death
Teardrop attack
WinNuke
3. Content monitoring and filtering
Fragment reassembly
Antivirus scanning
Antispam filtering
Web filtering
4. Deep inspection
• Stateful signatures
• Protocol anomalies
• Granular blocking of HTTP components
5. Intrusion detection and prevention

DN0976647 © 2014 Nokia Networks 71 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

6. Suspicious packet attributes

• ICMP fragments
• Large ICMP packets
• Bad IP options
• Unknown protocols
• IP packet fragments
• SYN fragments
In the next sub-sections only some mechanisms are described.

6.3.2.1 Reconnaissance deterrence

IP address sweep
An address sweep occurs when one source IP address sends 10 ICMP
packets to different hosts within a defined interval (5000 microseconds is the
default). The purpose of this scheme is to send ICMP packets—typically echo
requests—to various hosts in the hopes that at least one replies, thus
uncovering an address to target. The security device internally logs the
number of ICMP packets to different addresses from one remote source.
Using the default settings, if a remote host sends ICMP traffic to 10 addresses
in 0.005 seconds (5000 microseconds), the security device flags this as an
address sweep attack, and rejects all further ICMP echo requests from that
host for the remainder of the specified threshold time period.
It is suggested to enable this measure on the untrust zone.

Port scanning
A port scan occurs when one source IP address sends IP packets containing
TCP SYN segments to 10 different ports at the same destination IP address
within a defined interval (5000 microseconds is the default). The purpose of
this scheme is to scan the available services in the hopes that at least one
port will respond, thus identifying a service to target. The security device
internally logs the number of different ports scanned from one remote source.
Using the default settings, if a remote host scans 10 ports in 0.005 seconds
(5000 microseconds), the device flags this as a port scan attack and rejects all
further packets from the remote source for the remainder of the specified
timeout period.
It is suggested to enable this measure on the untrust zone.

TCP/UDP sweep protection

This measure limits the number of packets allowed from a source IP to
multiple IPs within a particular time frame. If the number of packets exceeds
the threshold limit, the device does not establish the session.

DN0976647 © 2014 Nokia Networks 72 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

It is not suggested to configure this measure, due to possibility that (if the
NetScreen thresholds are not well dimensioned) it may interfere with the
normal connection behavior among GSM network elements (especially for
UDP traffic flows).

Operating system probes

This measure blocks the anomalous TCP packets, having the purpose to
discover the kind of OS supported within equipments in BSS site.
It is suggested to enable this measure on the untrust zone.

Evasion techniques
One of the Evasion techniques is the Non-SYN Flags and this measure
avoids accepting TCP packets not being part of a regular TCP session (i.e. a
session initiated by a TCP SYN packet).
It is suggested to enable this measure on the untrust zone.
Another evasion technique is the IP spoof checking, i.e. it is the mechanism
to detect IP spoofing relies on route table entries. If, for example, a packet with
source IP address 10.1.1.6 arrives at ethernet3, but the NetScreen has a route
to 10.1.1.0/24 through ethernet1, IP spoof checking notes that this address
arrived at an invalid interface—as defined in the route table, a valid packet
from 10.1.1.6 can only arrive via ethernet1, not ethernet3.Therefore, the
device concludes that the packet has a spoofed source IP address and
discards it.
Measures not suggested, because it may introduce not-deterministic
behaviors of NetScreen during e.g. routing table updates.

6.3.2.2 Denial of service (DoS) attack defenses

Defenses against DoS attacks to firewall

Countermeasures to protect from NetScreen’s session table flood:
It may be useful to configure some of the measurement to protect Firewall
session table from flooding.

Defenses against DoS attacks to BSS site

• Syn flood protection:
A SYN flood occurs when a host becomes so overwhelmed by
SYN segments initiating incomplete connection requests that it can
no longer process legitimate connection requests.
This is a suggested measure on the untrust zone. Careful
configuration of thresholds is needed.
• ICMP flood protection:

DN0976647 © 2014 Nokia Networks 73 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

When enabling the ICMP flood protection feature, you can set a
threshold that once exceeded invokes the ICMP flood attack
protection feature. (The default threshold value is 1000 packets
per second.) If the threshold is exceeded, the security device
ignores further ICMP echo requests for the remainder of that
second plus the next second as well.
This is a suggested measure to be configured in untrust zone.
• UDP flood protection:
Similar to the ICMP flood, UDP flooding occurs when an attacker
sends IP packets containing UDP datagrams with the purpose of
slowing down the victim to the point that it can no longer handle
valid connections. After enabling the UDP flood protection feature,
you can set a threshold that, once exceeded, invokes the UDP
flood attack protection feature. (The default threshold value is 1000
packets per second). If the number of UDP datagrams from one or
more sources to a single destination exceeds this threshold, the
security device ignores further UDP datagrams to that destination
for the remainder of that second plus the next second as well.
It is suggested to implement such a feature only if it may be well
dimensioned. Otherwise it could disturb the communication
among GSM RAN equipments.
• Land Attack protection
A land attack occurs when an attacker sends spoofed SYN
packets containing the IP address of the victim as both the
destination and source IP address. The receiving system responds
by sending the SYN-ACK packet to itself, creating an empty
connection that lasts until the idle timeout value is reached.
Flooding a system with such empty connections can overwhelm
the system, causing a denial of service.
It is suggested to configure the Land attack protection in Untrust
zone
• Ping of Death protection
Many ping implementations allow the user to specify a packet size
larger than 65,507 bytes. A grossly oversized ICMP packet can
trigger a range of adverse system reactions such as denial of
service (DoS), crashing, freezing, and rebooting. When the Ping of
Death protection is enabled , the security device detects and
rejects such oversized and irregular packet sizes, even when the
attacker hides the total packet size by purposefully fragmenting it.
It is suggested to configure the Ping of Death protection in Untrust
zone.
• Teardrop attack protection

DN0976647 © 2014 Nokia Networks 74 / 78

Issue 01C
BSC TRANSPORT SITE SOLUTION BSC site solution: SGW Setup

Teardrop attacks exploit the reassembly of fragmented IP packets.

In the IP header, one of the fields is the fragment offset field, which
indicates the starting position, or offset, of the data contained in a
fragmented packet relative to the data of the original not-
fragmented packet. When the sum of the offset and size of one
fragmented packet differ from that of the next fragmented packet,
the packets overlap, and the server attempting to reassemble the
packet can crash, especially if it is running an older operating
system that has this vulnerability.
After enabling of the Teardrop Attack protection, whenever the
device detects this discrepancy in a fragmented packet, it drops it.
It is suggested to configure the Teardrop attack protection in
untrust zone

6.3.2.3 Content monitoring and filtering

These measures are not needed because they are related to monitor HTTP
traffic for malicious URLs, to perform antivirus (AV) scanning and Web
filtering. These issues don’t impact the protocols handled by BSC.

6.3.2.4 Deep inspection

This kind of inspection will not be used because it relates to application-layer
inspection in order to find specific traffic patterns related to a documented
attack or protocol anomalies. These measures are mainly intended to protect
mainly server farms or personal computers, so they are not covering the
needs of telecommunication equipment sites.

6.3.2.5 Intrusion detection and prevention

This functionality is “de facto” similar to deep inspection, so the same
considerations apply also here.

6.3.2.6 Protection from suspicious packet attributes

Sometimes it is unclear what the intent of a crafted packet is, but the very fact
that it is crafted suggests that it is being put to some kind of insidious use.
These measures block suspicious packets that might contain hidden threats.
In particular the measures concern blocking of:
• Large ICMP Packets
• Bad IP Options
• Syn fragments
These rules are suggested. They have to be configured at untrust interface.

DN0976647 © 2014 Nokia Networks 75 / 78

Issue 01C
 BSC TRANSPORT SITE SOLUTION SGW Requirements Compliance

7 SGW Requirements Compliance

Req ID Name and description Priority Juniper
NetScreen
E_001 Routing, VLAN and QoS functionalities. M Compliant
SGW shall implement IPv4. Support of IPv6 is optional.
SGW shall support Routing and related protocols (OSPF)
SGW shall support QoS aware packet scheduling at every
aggregation point in the node according to DSCPs as defined in
RFC2474 /10/ and RFC2475 /11/.
SGW shall copy DSCP field from inner to outer IP header and vice
versa.
SGW shall copy TTL/Hop Limit field in the inner IP header to the
outer header when encapsulated
SGW shall support configurable mapping of DSCPs to Ethernet
priorities carried in VLAN-PCP bits
SGW shall support termination of Ethernet interfaces including
VLAN functionality
SGW shall support Link aggregation towards transport network
SGW shall support ICMP, including e.g. echo request, echo reply
and destination unreachable
E_002 IKE Features for Packet Abis traffic: M Compliant
In order to set-up the IPSEC Security Association SGW shall Juniper NetScreen
support the IKE protocol. is able to create
multiple Child
In particular SGW for establishing SA with GSM BTS shall support:
under the same
- IKE version 2 according to RFC 4306 /12/; IKE_SA.
- IKE exchanged mode: main;
- IKE authentication: X.509 certificates and Pre-Shared Key;
- IKE SA encryption algorithm:
AES128-CBC (Initialization Vector to be initialized with a random
value for each encryption process; solution shall be compliant with
3GPP 33.210 and RFC 3602 – AES-CBC and its use with IPsec),

DN0976647 © 2014 Nokia Networks 76 / 78

Issue 01C
 BSC TRANSPORT SITE SOLUTION SGW Requirements Compliance

3DES-192 CBC;
- IKE SA authentication/integrity protection HMAC-SHA1-96;
- Diffie-Hellmann group 2.
- NAT-T negotiation is not required at Abis side because GSM Flexi
EDGE BTS/FlexiMultiRadio BTS does not implement NAT-t.

- Remote peer’s IKE Id shall be checked by verifying that remote

peer's certificate is valid and has the same CA as the certificate of
the local IKE Id. This is aligned to current assumption in WCDMA.
E_003 IKE Features for other interfaces different from Abis: M Compliant
In addition to IKEv2 also IKEv1 is required in case of a remote
SGW at CN or at NetAct side uses IKEv1.
IKE is necessary for establish automatically key to be used in
IPSEC SA.
IKE v2 is required because Nokia
FlexiEDGEBTS/FlexiMultiRadioBTS supports only IKEv2, while
IKEv1 may be used by SGW at NetAct or CN site depending on
operator choice.
E_004 IPSEC ESP features M Compliant
Features for Abis traffic:
SGW shall be able to provide IPsec authentication and integrity on
Abis interface as following:
- IPSE ESP tunnel mode
- Encapsulating Security Protocol (ESP);
- IPsec SA authentication/integrity protection: HMAC-SHA1-96;
- No compression.

SGW shall be able to provide IPsec encryption on Abis interface as

following:
- IPSE ESP tunnel mode
- Encapsulating Security Payload (ESP);
- IPsec SA encryption algorithm: AES128-CBC (Initialization Vector
to be initialized with a random value for each encryption process;
solution shall be compliant with 3GPP 33.210 and RFC 3602 - AES-
CBC and its use with IPsec), 3DES-192 CBC, NULL
ENCRYPTION;
- No compression.

Features for NETACT towards NetAct: IPSec is internal in BSC.

Features for AoIP and SIGTRAN traffic towards CN:

DN0976647 © 2014 Nokia Networks 77 / 78

Issue 01C
 BSC TRANSPORT SITE SOLUTION SGW Requirements Compliance

Feature of SGW at BSC Site and SGW at CN Site have to be

compatible.
E_005 Certificate Support M Compliant
SGW shall support X.509v3 Certificate according to RFC 4210.
SGW shall support manual or automatic enrollment.

DN0976647 © 2014 Nokia Networks 78 / 78

Issue 01C