The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
The following sections describe the WSG and Cisco Service and Application Module for IP (SAMI).
The WSG is a high-density IP Security (IPSec) gateway for mobile wireless carrier networks. IPSec is an open standards set. IPSec provides confidentiality, integrity, and authentication for data between IP layer peers. The WSG uses an IPSec-protected tunnel to connect outside endpoints.
Figure 1-1 shows a WSG in a Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN).
Figure 1-1 WSG Implementation in a UTRAN
The WSG application runs on the Cisco SAMI. The SAMI offers the following features:
Using the Supervisor (SUP) Engine, virtual local area networks (VLANs) direct traffic from outside ports to each instance of the WSG on PPCs. A 10 Gigabit Ethernet port on the backplane connects the SAMI and the SUP.
From the SUP, start a session to each WSG instance. This allows you to do the following with the WSG:
For more information about the SAMI, see the Cisco Service and Application Module for IP User Guide.
This process shows how the WSG installs on a SAMI:
1. SAMI’s SUP downloads the WSG application.
2. The SUP sends the WSG image to each of the SAMI’s six PPCs.
3. The same WSG image installs on all of the PPCs.
After installing the WSG, individually set up each PPC. Use SAMI’s remote console and logging (RCAL) to log into the SUP. This acts as a single connection to access the SAMI linecard control processor (LCP) and the PPCs. Using the SUP you can:
WSG ships loaded on SAMI PPCs with fully-functional defaults that support the following features.
The following feature is reverted in WSG Release 4.4.8a and above:
The following features are supported in WSG Release 4.4.8 and above:
The following features are supported in WSG Release 4.4.6 and above:
Note From WSG Release 4.4.8a, support for maximum of 32 service interface IPs per PPC has been reverted. Which means, only 10 service interface IPs per PPC are supported.
The following features are supported in WSG Release 4.4.5 and above:
Note Sharing of the same VLAN ID on different PPC’s of SAMI WSG is not supported. However, sharing of service VLAN ID is allowed on different PPC’s of SAMI WSG.
The following features are supported in WSG Release 4.4.3 and above:
The following features are supported in WSG Release 4.4.1 and above:
The following features are supported in WSG Release 4.4 and above:
The following features are supported in WSG Release 4.3.2 and above:
The following features are supported in WSG Release 4.3 and above:
Note DHCP is supported for RAS profiles and not for site-to-site profiles.
The following features are supported in WSG Release 4.2 and above:
– Synchronized Statistics collection start times across all SAMI blades in a chassis using a NTP clock
– Real time statistics collection for CLIs similar to previous releases
– Auto adjustment of statistics collection interval based on the number of SAs
– Configurable fixed statistics collection interval length
– Persistent IKE/IPSec tunnel index for SNMP during a tunnel's lifetime
– Alignment of IKE/IPSec global and per-tunnel statistics
The following features are supported in WSG Release 4.0 and above:
The following features are supported in WSG Release 3.1 and above:
The following features are supported in WSG Release 3.0 and above:
The typical case for this is an ISP that provides VPN service to multiple enterprise customers on the same box, the users and branches connect using internet for the encrypted traffic, but the decrypted traffic needs to go to the private network of each separate customer and this traffic cannot be mixed.
Prior to WSG Release 3.0, all return traffic between the WSG and the SUP is carried over the same VLAN. It is not desirable for customers to have all their traffic converge onto the same VLAN at any point in the packet path. This feature supports true dual-arm implementation. Traffic on the clear and protected sides traverse different VLANs.
A static routing table for IPv4/IPv6 is maintained on IXP for forwarding packets out to the correct VLAN. IPv4/IPv6 static routes are configured on the PPC. On the same PPC, two identical routes can be present in different VRFs. In case of more than one match in the routing table, the longest prefix approach is used. The maximum number of static routes per VRF per PPC is 10. The maximum number of static routes per WSG is 60. Dynamic routing is not supported in WSG Release 3.0.
There is no support for groups or privileges configuration. All users have the same privilege. Admin Group or role assignments are not supported. The number of users that can be configured are limited by the size of the configuration file. There is no timeout on the SSH sessions. The user cannot kill a session from the CLI.
WSG supports per peer debugging of tunnel setup and IKE protocol exchanges by allowing the peer IP address to be specified when turning on debugs.
Introduced in WSG Release 3.0, the RRI feature obviates the need to manually configure static routes on the SUP for clear traffic routing purposes in the reverse direction. RRI route entries are injected into the SUP when IPSec tunnels are created. These route entries are correspondingly withdrawn from the SUP when the IPSec tunnels are deleted. The BGP protocol is used to re-distribute the routes from WSG to the SUP. For WSG Release 3.0, the RRI feature supports only IPv4. Also, only site-to-site profiles are supported. The VRF feature on the WSG cannot be enabled when the RRI feature is already configured.
In some Femto networks, an Access Point (AP) sets up an IPSec tunnel with the WSG and sends an Iuh Register message via the tunnel to a Femto Gateway (FGW). The Iuh Register message is an IP packet which also contains the ID of the AP registering with the FGW. The ID used by the AP is the same as the IKE ID used by the AP during IPSec tunnel setup. The FGW needs to make sure that an authenticated AP is not presenting itself as another AP during registration. This can be achieved by the FGW by comparing the source IP address of the Iuh Register packet with the internal IP address assigned by the WSG for the same AP (ID is the lookup key). For this to work, the WSG needs to send the ID to internal IP address mapping to the FGW every time it assigns an IP to the AP. RADIUS Accounting messages are used to send the IKE ID to assigned IP address mapping from the WSG to the AAA server running in the FGW.
The blacklisting feature is a mechanism to prevent a remote peer from setting up a tunnel to the WSG. With the blacklisting feature, when a remote peer attempts to setup a tunnel with the WSG, the IKE ID of the remote peer is searched for in a blacklist file available to the WSG. If a match is found, the IKE AUTH request is failed and the remote peer is prevented from establishing a tunnel. The blacklisting feature provides a fast and simple mechanism to block a remote peer from setting up a tunnel to the WSG.
Remote peers can negotiate multiple proposals during IKE Phase 1. Each proposal contains one or more encryptions, integrity, prf and DH group algorithms. WSG accepts multiple proposals during IKE SA setup and rekey.
WSG Release 2.0 and above supports inter-chassis stateful 1:1 redundancy. Redundancy works at the SAMI level. All 6 PPCs on a SAMI are in active or hot standby state. The PPC of the active WSG syncs its state to the corresponding PPC of the redundant WSG (for example, PPC3 (A) to PPC3 (S).
The WSG redundancy feature works with all IPSec supported features including IKEv1, IKEv2, ESN, anti-replay, DPD, and NAT-traversal. WSG redundancy is applicable to both remote access and site-to-site tunnels.
If a primary card fails, traffic is switched to the newly active SAMI. The established tunnels stay up and continue to pass traffic after failover, and the IKE/IPSec internal state is synced between the active and redundant WSGs. Traffic outage is less than 1 second after the failure detection.
In previous releases, site-to-site traffic selector lookup was done by looking up an array of TS on the IXP. This linear search limited the performance of the site-to-site traffic selector lookup algorithm. For WSG Release 2.0 and above, the traffic selector lookup algorithm improves site-to-site performance. No change occurs for remote access traffic selector lookup; it is different from the lookup algorithm for site-to-site, and is already optimized.
Up to 16666 S2S tunnels are supported per SAMI blade. S2S tunnels can only be configured on the director PPC.
IKE protocol allows a peer to negotiate multiple TS for the same tunnel. However, in WSG Release 2.0 each tunnel can negotiate only one TS.
All other features that are currently supported for site-to-site and remote access are maintained.
WSG Release 2.0 introduced support for Certificate Management Protocol (CMPv2).
The user manually requests the initial key or certificate from the CA server using the crypto cmp initialize command. The initial request is authenticated using the reference number and pre-shared key (PSK) from the CA server using an out-of-band mechanism. After receiving the initial certificate, the crypto cmp enroll command is used to enroll the certificate using the public key. Prior to the certificate expiration, the crypto cmp update command is used to update the certificate and private key. The WSG changes the name of the certificate and private key files during the update, so any WSG configuration commands which use the previous certificate file names must be replaced with commands using the new file names (configuration commands with wsg-cert or current-wsg-cert keywords). After the initialize, enroll, and update commands, the certificate and private key files are copied from the WSG to the SUPs in the Cisco 7600 chassis. The files must be manually copied to the SUP on other Cisco 7600 chassis.
WSG Release 3.0 introduced an automatic certificate renewal mechanism. The crypto cmp auto-update configuration command may be used on a WSG to automatically update the certificate and private key and send them to its SUPs. The crypto cert renewal retrieve configuration command is used on other WSGs to retrieve the updated certificate from the Cisco 7600 SUPs. Both commands are global configuration commands, thus the configuration is saved. In a HA configuration, both commands update the standby WSG, which then updates their SUPs. If inter-chassis redundancy is configured, the certificate and private key will be propagated to redundant chassis. A WSG may be configured to automatically update some certificates and automatically retrieve others. The maximum number of certificates that may be configured for automatic renewal (update and retrieve) is 20.
Syslog messages and two SNMP traps, cert-expiry and cert-renewal, were introduced for CMPv2 in WSG Release 3.0. The crypto pki wsg-cert-trap expiry notification configuration command may be used to configure a cert-expiry trap and syslog up to 30 days before a WSG certificate is about to expire (default is 24 hours). The cert-renewal trap and syslog will provide notifications for the automatic update or retrieve status, which may be configured to start 2 to 60 days before the certificate will expire. The SNMP traps are enabled using the snmp-server enable traps ipsec configuration command.
In previous releases, the WSG used CRL (Certificate Revocation List) to obtain from the CRL server, a file containing the list of certificates that were revoked.
In WSG Release 2.0 the Online Certificate Status Protocol (OCSP) feature was introduced to address some of the limitations of CRL. OCSP works to achieve the same objective as the CRL mechanism; it determines if a certificate offered by a peer has been revoked. OCSP differs from CRL in that the revocation status is obtained on a per-certificate basis rather than a trust anchor basis. Since the revocation status is obtained when the certificate is first seen by the WSG, the status is up to date.
– Negotiates IKE and security associations (SAs)
– Sets up encryption algorithms keys
IPSec SAs are secured links in one direction. IPSec endpoints must authenticate themselves to each other and set up Internet Security Association and Key Management Protocol (ISAKMP) shared keys.
WSG uses the IKEv1 or IKEv2 protocols to communicate with the IPSec endpoint to set up an Encapsulating Security Payload (ESP)-encapsulated tunnel. This tunnel gives protected access to a private network. The WSG encapsulates, encrypts, and authenticates packets from private networks to IPSec endpoints. In the reverse direction, the WSG decapsulates, decrypts, and authenticates.
The DPD initiation feature allows the WSG to send DPD to peers at a regular interval. This allows WSG to detect and remove dead connections or peers. This feature is independent of existing functionality where the SAMI responds to DPD messages from its peer. The SAMI is able to both initiate DPD and respond to DPD at the same time.
– Destination IP address range
For a single IKE association with a peer, multiple child IPSec SAs can be created, each with its own traffic selector rule. We support one traffic selector per child IPSec SA.
In WSG Release 1.2 and above, DH Groups 14, 15, 16, 17, and 18 are added to groups 1, 2 and 5. DH is a public-key cryptography protocol. It allows two parties to set up a shared secret key used by encryption algorithms over an insecure communications channel. DH is used within IKE to set up session keys.
The following features were introduced prior to WSG Release 1.2 and are still applicable:
The SA is kept by each peer until its lifetime expires. Because new SAs are negotiated before current SAs expire, they can be reused to save time. Shorter lifetimes mean more secure negotiations. Longer lifetimes mean SAs are more quickly set up.
WSG supports the following IKE secret encryption schemes:
– Data Encryption Standard (DES)
– Triple DES (3DES), also known as Triple Data Encryption Algorithm (3TDEA)
– Advanced Encryption Standard (AES) (128, 192, 256)
The WSG supports IKE NAT traversal by encapsulating the ESP payload over UDP as in RFC 3948. The WSG listens for IKE messages on UDP ports 500 and 4500. When it receives an IKE request the WSG responds to the address and port from which the request is received. With NAT Detection Source/Destination IP notifications, if the WSG detects that the peer is behind a NAT device, it sets up an ESP tunnel to be UDP encapsulated.
The digital certificate is a package containing information such as the identity of a certificate bearer: his or her name or IP address, the certificate’s serial number, the certificate’s expiration date, and a copy of the certificate bearer’s public key. The standard digital certificate format is defined in the X.509 specification.
For additional information, refer to these RFCs: