Transport Mode provides a secure connection between two endpoints as it encapsulates IP payload, while Tunnel Mode encapsulates the entire IP packet to provide a virtual "secure hop" between two gateways.

Tunnel Mode forms the more familiar VPN functionality, where entire IP packets are encapsulated inside another and delivered to the destination. It encapsulates the full IP header as well as the payload.

An Internet Key Exchange-Security Association (IKE-SA) is used to secure IKE comicality. SA is identified by two, eight-byte Security Parameter Indices (SPIs) shared by each peer during the initial IKE exchange. Both SPIs are carried in all subsequent messages.

A Child-SA is created by IKE for use in AH or ESP security. Two Child-SAs are created as a result of one exchange – Inbound and Outbound. A Child-SA is identified by a single four-byte SPI, Protocol and Gateway IP Address and is carried in each AH/ESP packet.

Each SA (IKE or Child) has an associated lifetime. After the expiry of lifetime, SAs are deleted. To proactively establish an SA before the last one expires, SAs are rekeyed on soft lifetime expiry. Both IKE and Child SAs may be rekeyed.

Anti-replay is a sub-protocol of IPSec (RFC 4303) that is supported for IKEv1 and IKEv2 tunnels. Its main goal is to prevent hackers injecting or making changes in packets that travel from a source to a destination. Anti-replay protocol employs a unidirectional security association to establish a secure connection between two nodes in the network.

Once a secure connection is established, the anti-replay protocol uses a sequence number or a counter. When the source sends a message, it adds a sequence number to its packet starting at 0 and increments every time it sends another message. At the destination end, the protocol receives the message and keeps a history of the number and shifts it as the new number. If the next message has a lower number, the destination drops the packet, and, if the number is larger than the previous one, it keeps and shifts it as the new number.

The anti-replay feature may be enabled or disabled via the StarOS CLI. Anti-Replay Window Sizes of 32, 64, 128, 256, 384 and 512 bits are supported (default = 64 bits).

IPSec can be implemented via StarOS for the following applications:

Figure 1. IPSec Applications

Note that: IPSec can be implemented for both attribute-based and compulsory tunneling applications for 3GPP2 services.

Access Control Lists define rules, usually permissions, for handling subscriber data packets that meet certain criteria. Crypto ACLs, however, define the criteria that must be met in order for a subscriber data packet to be routed over an IPSec tunnel.

Unlike other ACLs that are applied to interfaces, contexts, or one or more subscribers, crypto ACLs are matched with crypto maps. In addition, crypto ACLs contain only a single rule while other ACL types can consist of multiple rules.

Prior to routing, the system examines the properties of each subscriber data packet. If the packet properties match the criteria specified in the crypto ACL, the system will initiate the IPSec policy dictated by the crypto map.

For additional information refer to the Access Control chapter of this guide. There you will find a discussion of blacking and whitelisting, as well as IKE Call Admission Control (CAC).

Transform Sets are used to define IPSec security associations (SAs). IPSec SAs specify the IPSec protocols to use to protect packets.

Transform sets are used during Phase 2 of IPSec establishment. In this phase, the system and a peer security gateway negotiate one or more transform sets (IPSec SAs) containing the rules for protecting packets. This negotiation ensures that both peers can properly protect and process the packets.

For additional information refer to the Transform Set Configuration chapter of this guide,

Internet Security Association Key Management Protocol (ISAKMP) policies are used to define Internet Key Exchange (IKE) SAs. The IKE SAs dictate the shared security parameters (such as which encryption parameters to use, how to authenticate the remote peer, etc.) between the system and a peer security gateway.

During Phase 1 of IPSec establishment, the system and a peer security gateway negotiate IKE SAs. These SAs are used to protect subsequent communications between the peers including the IPSec SA negotiation process.

For additional information refer to the ISAKMP Policy Configuration chapter of this guide.

Crypto Maps define the tunnel policies that determine how IPSec is implemented for subscriber data packets.

A Crypto Template configures an IKEv2 IPSec policy. It includes most of the IPSec parameters and IKEv2 dynamic parameters for cryptographic and authentication algorithms. A security gateway service will not function without a configured crypto template.

Only one crypto template can be configured per service. However, a single StarOS instance can run multiple instances of the same service with each associated with that crypto template.

For additional information, refer to the Crypto Templates chapter of this guide.