Product Overview
The SecGW is a high-density IP Security (IPSec) gateway for mobile wireless carrier networks. It is typically used to secure backhaul traffic between the Radio Access Network (RAN) and the operator core network.
IPSec is an open standards set that provides confidentiality, integrity, and authentication for data between IP layer peers. The SecGW uses IPSec-protected tunnels to connect outside endpoints. SecGW implements the parts of IKE/IPSec required for its role in mobile networks.
The SecGW is enabled as a Wireless Security Gateway (WSG) service in a StarOS instance running in a virtual machine on a Virtualized Services Module (VSM) in an ASR 9000.
-
S1-C and S1-U: Control and User Traffic between eNodeB and EPC
-
X2-C and X2-U: Control and User Traffic between eNodeBs during Handoff
-
SPs typically carry only Control Traffic, however there exists a case for carrying non-Internet User traffic over secured tunnels
ASR 9000 VSM
SecGW is enabled via a StarOS image running in a virtualized environment supported on the ASR 9000 VSM. StarOS runs in four hypervisor-initiated virtual machines (one per CPU) on the VSM.
Also SecGW Suppors VPC-DI platform.
The VSM is a service blade for the ASR 9000 router that supports multiple services and applications running simultaneously on top of a virtualized hardware environment.
The VSM supports the following major hardware components:
-
(4) CPUs [20 cores per socket]
-
(4) hardware crypto devices
-
(1) Data Path Switch supporting (12) 10 Gigabit Ethernet (GbE) devices
-
(2) NPUs
The ASR 9000 services architecture encompasses how the platform interfaces with the services independent of where the service is actually instantiated. It provides a common control plane, management plane and data plane infrastructure such that a consistent end user experience is provided whether the service is running on a service blade, on the RSP, on an attached appliance or server, or even running inline in the router.
-
Enables services via IOS-XR
-
Provides platform management via CLI and XML for:
-
Service parameter specification
-
Validation of service package including licenses
-
Service instantiation with associated parameters
-
Service health monitoring
-
Service termination, re-start and upgrades
-
-
Decouples configuration of the WSG service from the service creation infrastructure
-
Provides a set of templates for service parameters
-
Interfaces with the hypervisor (Virtual Machine Manager client) to setup the StarOS WSG service on multiple virtual machines (VMs)
The figure below shows the relationship between IOS-XR running on the ASR 9000 and StarOS running on the VSM.
The 10GE interfaces on the SecGW virtual machines are visible as 10GbE interfaces on the ASR 9000. The ASR 9000 line card forwards IP traffic to VSM 10GbE ports.
VSM Resource Mapping to VPC-VSM VMs
There are four CPU sockets on the VSM. Each CPU supports multiple cores. A VPC-VSM instance uses multiple virtual CPUs (vCPUs) consisting of available cores for its virtual machine.
Each CPU socket is associated with a Crypto engine. PCI Ports are also assigned to accept traffic from the ASR 9000 line cards.
The table below shows how resources are assigned among the four CPUs on the VSM.
CPU | Available Cores | Crypto Device | PCI Port ID | VM | vCPUs |
---|---|---|---|---|---|
0 | 16 (2–9, 42–49) | 04:00.0 | 00.0.0 | VM1 | 16 |
00.0.1 | |||||
1 | 18 (11–19, 51–59) | 45.00.0 | 42.0.0 | ||
42.0.1 | VM2 | 16 | |||
48.0.0 | |||||
48.0.1 | |||||
2 | 20 (20-29, 60-69) | 85:00.0 | 82:0.0 | VM3 | 20 |
82:0.1 | |||||
88:0.0 | |||||
88:0.1 | — | — | |||
3 | 20 (30-39, 70-79) | C5:00.0 | C2:0.0 | VM4 | 20 |
C2:0.1 | |||||
C8:0.0 | |||||
C8:0.1 | — | — |
Only twelve PCI ports can be mapped to ASR 9000 line card traffic. The table below shows how the interfaces are distributed.
PCI Port ID | CPU | ASR 9000 TenG | VPC Slot/Port | VM | Application IF |
---|---|---|---|---|---|
00:0.0 | 0 | TenGx/y/z/0 | 1/10 | VM1 | Uplink |
00:0.1 | TenGx/y/z/1 | 1/11 | Downlink | ||
42:0.0 | 1 | TenGx/y/z/2 | 1/1 | Management | |
42.0.1 | TenGx/y/z/3 | 1/10 | VM2 | Uplink | |
48.0.0 | TenGx/y/z/4 | 1/11 | Downlink | ||
48.0.1 | TenGx/y/z/5 | 1/1 | Management | ||
82:0.0 | 2 | TenGx/y/z/6 | 1/10 | VM3 | Uplink |
82:0.1 | TenGx/y/z/7 | 1/11 | Downlink | ||
88:0.0 | TenGx/y/z/8 | 1/1 | Management | ||
88:0.1 | — | — | — | Unused | |
C2:0.0 | 3 | TenGx/y/z/9 | 1/10 | VM4 | Uplink |
C2:0.1 | TenGx/y/z/10 | 1/11 | Downlink | ||
C8:0.0 | TenGx/y/z/11 | 1/1 | Management | ||
C8:0.1 | — | — | — | Unused |
- For all VMs except VM1, the NICs are allocated from the corresponding socket. But in VM1, the third NIC (42:0.0) is picked from a different socket. To achieve maximum throughput, that NIC is used as the management port and the other two are used for the service.
- To make the interface-to-port mapping symmetric across all the VMs, the third NIC is always used as the management port.
VPC-VSM
Virtualized Packet Core for VSM (VPC-VSM) consists of the set virtualized mobility functions that implement mobility specific services and applications within the core of the network. VPC-VSM is essentially StarOS running within a Virtual Machine (VM).
VPC-VSM only interacts with supported hypervisors. It has little or no knowledge of physical devices.
Each VPC-VSM VM takes on the roles of an entire StarOS system. The only interfaces exposed outside the VM are those for external management and service traffic. Each VM is managed independently.
- Controller tasks
- Out-of-band management for CLI and Logging
- Local context (management)
- NPU simulation via fastpath and slowpath
- Non-local context (subscriber traffic)
- Crypto processing (IPSec)
For a complete description of VPC-VSM functionality, refer to the VPC-VSM System Administration Guide.
Important |
Up to four instances of VPC-VSM can run on an ASR 9000 VSM. Each VSM CPU supports only one VPC-VSM instance. VSM resources are allocated to each SecGW VM; no other application VM is supported on any VSM CPU. vNICs must be passed to the SecGW VMs from RSP. |
SecGW Application
The StarOS-based Security Gateway (SecGW) application is a solution for Remote-Access (RAS) and Site-to-Site (S2S) mobile network environments. It is implemented via StarOS as a WSG (Wireless Security Gateway) service that leverages the IPSec features supported by StarOS.
SecGW delivers the S2S IP Encryption capabilities required in UMTS/HSPA and LTE 3GPP LTE/SAE network architectures.
For complete descriptions of supported IPSec features, see the IPSec Reference.
Important |
20.0.x is the last fully qualified build for ASR9k SecGW. |
Important |
The SecGW is a licensed StarOS feature. A separate license is required for each VPC-VSM instance and SecGW. Contact your Cisco account representative for detailed information on specific licensing requirements. |
Key Features
- Functions in a virtualized environment on one or more VSM blades in an ASR9000
- Supports IKEv2.
- Supports DES, 3DES, AES and NULL Encryption algorithms, and MD5, SHA1/2, HMAC-SHA2 and AES-XCBC Hash algorithms.
- Provides mechanisms for High Availability both within and outside of the ASR 9000 chassis.
- IPv6 support encompasses Inner-Outer pairs – v6-v6, v6-v4, v4-v6, v4-v4
- Allows dynamic provisioning of IPSec configuration for a new WSG service in the existing SecGW instance.
Each of the four SecGWs on a VSM must be configured separately.
Load balancing has not been implemented for the SecGWs; incoming calls will not be automatically distributed across the four SecGWs on a VSM. A workaround is to use VLANs for load balancing. The public side interface of each SecGW can be configured for a separate VLAN. Calls from multiple peers are routed to the same IP address via a different VLAN to distribute the traffic load.
IPSec Capabilities
- Anti Replay
- Multiple Child SA (MCSA)
- Certificate Management Protocol (CMPv2)
- Session Recovery/Interchassis Session Recovery for both RAS and S2S
- Support for IKE ID Type
- PSK support with up to 255 octets
- Online Certificate Status Protocol (OCSP)
- Reverse DNS Lookup for Peer IP in show Commands
- Blacklist/Whitelist by IDi
- Rekey Traffic Overlap
- CRL fetching with LDAPv3
- Sequence Number based Rekey
- IKE Call Admission Control (CAC)
- PSK Support for up to 1000 Remote Secrets
- Certificate Chaining
- RFC 5996 Compliance
- Duplicate Session Detection
- Extended Sequence Number
- Security Gateway as IKE Initiator
- Support to provide DNS server address to the Peer
Reverse Route Injection
SecGW also supports Reverse Route Injection (RRI). RRI injects routes in the reverse direction onto the ASR 9000 VSM so that clear traffic can be routed to the correct interface on the target VPC-VSM. For additional information, see the Reverse Route Injection chapter.
SecGW Management
Each SecGW instance is configured individually via its Management port. However, the Cisco Prime network management tool can be used to configure and manage individual SecGW instances.
A common or default configurations can be captured as "templates" in Cisco Prime which are then applied to each SecGW instance or all SecGW instances in the network.
For additional information on the Cisco Prime Mobility suite, contact your Cisco account representative.
Alternatively an operator can create a StarOS configuration file on the first gateway. The resulting configuration file can then be copied and edited offline with different parameters. The edited configuration file is then copied to the flash drive of the second SecGW. The process is repeated until all four SecGWs have been initially configured.
Subsequent changes made to the configuration of each SecGW must be saved to the local configuration file. For security and recovery the individual configuration files should then be saved off the VMS to a target network destination.
For additional information, see the VPC-VSM System Administration Guide.
oneP Communication
Each SecGW creates a oneP session with the ASR 9000 for route insertions, policy creation and flow creation. For additional information, refer to the oneP Communication chapter.