Key Exchange Protocols
Key exchange protocols enable secure communications over an untrusted network by deriving and distributing shared keys between two or more parties. The Internet Key Exchange (IKEv1) Protocol, originally defined in RFC 2409, provides a method for creating keys used by IPsec tunnels. Session Description Protocol Security Descriptions for Media Streams (SDES), defined in RFC 4568, provides alternative methods for creating keys used to encrypt Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP) transactions.
Each of these protocols is described in the following sections.
IKEv1 Protocol
IKEv1 is specified by a series of RFCs, specifically RFCs 2401 through 2412. The most relevant are:
- RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP
- RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
- RFC 2409, The Internet Key Exchange (IKE)
- RFC 2412, Oakley Key Determination Protocol
IKEv1 combines features of the Internet Security Association and Key Management Protocol (ISAKMP) and Oakley Key Determination Protocol in order to negotiate Security Associations (SA) for two communicating peers. IKEv1 also provides for key agreement using Diffie-Hellman.
IKEv1 uses two phases. Phase 1 is used to establish an ISAKMP Security Association for IKEv1 itself. Phase 1 negotiates the authentication method and symmetric encryption algorithm to be used. Phase 1 requires either six messages (main mode) or three messages (aggressive mode).
Phase 2 negotiates the SA for two IPsec peers and is accomplished with three messages.
The initial IKEv1 implementation supports RFC 2409, Internet Key Exchange, and RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.
IKEv1 Configuration
IKEv1 configuration consists of five steps.
- Configure IKEv1 global parameters.
- Optionally, enable and configure Dead Peer Detection (DPD) Protocol.
- Configure IKEv1 interfaces.
- Configure IKEv1 Security Associations (SA).
- Assign the IKEv1 SA to an IPsec Security Policy.
IKEv2 Protocol
IKEv2 is specified by a series of RFCs, specifically RFCs 2401 through 2412. The most relevant are:
- RFC 2412, Oakley Key Determination Protocol
- RFC 4301, Security Architecture for the Internet Protocol
- RFC 4306, Internet Key Exchange (IKEv2) Protocol
- RFC 4718, IKEv2 Clarifications and Implementation Guidelines
- RFC 5996, Internet Key Exchange (IKEv2) Protocol
IKEv2 combines features of the Internet Security Association and Key Management Protocol (ISAKMP) and Oakley Key Determination Protocol in order to negotiate Security Associations (SA) for two communicating peers. IKEv2 also provides for key agreement using Diffie-Hellman.
The initial IKEv2 implementation supports RFC 4306, Internet Key Exchange (IKEv2) Protocol, and RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.
IKEv2 Support
The Oracle Communications Session Border Controller (SBC) supports version 2 of the Internet Key Exchange (IKE) protocol. IKEv2 provides an initial handshake in which IKE peers negotiate cryptographic algorithms, mutually authenticate, and establish session keys to create an IKEv2 Security Association (SA) and an IPsec SA.
Key elements of IKEv2 support include:
- Peering/SIP Trunking solutions and access-side use cases
- Mutual authentication
between the
SBC and its peers,
including:
- IKE rekey
- Dead Peer Detection (DPD)
- Initiator mode
- Responder mode
- Per-interface IKEv2 configuration
- Simultaneous support of IKEv1 and IKEv2 protocols
- Either tunnel or transport mode supported per IKE interface
- Transcoding
- Separate interfaces and IP addressing for SIP and IKE for related traffic
- Certificate-based authentication during IKEv2 tunnel establishment
- Multiple endpoints beyond tunnel remote address
With respect to IKE, if the peer does not support any of the encryption, hashing and integrity algorithms and Diffie Hellman groups supported by the SBC, it rejects the IKEv2 establishment. With respect to IPsec, if the peer does not support any of the encryption, hashing and integrity algorithms supported by the SBC, it does not create the child SA.
This can be implemented by removing these from the default list but allow manual configuration to add support.
At the IKEv2 global configuration level, users can do the following:
- Configure IKEv2 global parameters.
- Configure a default certificate profile.
- Configure one or more RADIUS authentication servers (optional).
- Configure one or more RADIUS authorization servers (optional).
- Configure the default address pool (optional).
- Configure pre-shared-keys if authentication is based on the contents of the IKEv2 Identification payload (optional).
To a large extent, global configuration establishes profiles that either apply to specific traffic and interfaces or you apply to elements by further configuration. To the extent that there is any overlapping configuration, the interface level takes precedence over global configuration.
IKEv2 Global Configuration
This section covers IKEv2 global configuration parameters, omitting IKEv1 parameters. A parameter within the global ike-config element can be overridden by the same parameter within the ike-interface element.
RADIUS Authentication
All EAP-based authentication is performed by RADIUS servers. When such authentication is specified, the Oracle Communications Session Border Controller operates as a relay between the remote IKVv2 peer and a RADIUS authentication server.
Configuring RADIUS Authentication
RADIUS authentication support requires:
- configuration of a pool of RADIUS authentication servers, with each server configuration record providing all values required for server access
- configuration of a RADIUS Authentication Servers List designating specific pool member as being available for authentication purposes
- assignment of the RADIUS Authentication Servers List to the authentication configuration object
Tearing Down IPsec Tunnels
If EAP-based authentication is used in conjunction with RADIUS-based assignment of requested local addresses, the Oracle Communications Session Border Controller responds to a Disconnect-Request message (as defined in RFC 5176, Dynamic Authorization Extensions to Remote Authentication Dial-In User Service) received from a configured RADIUS server.
The SBC parses the received Disconnect-Request for User-Name and Framed-IP-address attribute values. If the User-Name value matches the authenticated EAP identity, and the Framed-IP-address value matches the inner IP address assigned to the authenticated endpoint, the SBC deletes the IPsec tunnel described by the received values. Tunnel deletion is reported to the RADIUS server with a Disconnect-ACK message, which, in conformity to Section 3.5 of RFC 5176, contains an Error Cause of 201 indicating Residual Session Context Removed.
If the IPsec tunnel cannot be deleted because of faulty/incorrect User-Name and/or Framed-IP-address values, the SBC returns a Disconnect-NACK message, which, in conformity to Section 3.5 of RFC 5176, contains an Error Cause of 404 indicating Invalid Request.
Enable RADIUS Authorization
Complete RADIUS authorization configuration by enabling RADIUS authorization on an IKEv2 interface.
Local Address Pool Configuration
If your network environment requires local address pools that serve as a source of IPv4 or IPv6 addresses temporarily leased for use by remote IKEv2 peers, use the procedures in the following two sections to configure such pools.
During the IKE_AUTH exchange, the IPsec initiator (the remote endpoint) often requests an internal IP address from an IPsec responder (the Oracle Communications Session Border Controller). Refer to Section 2.19 of RFC 7296, Internet Key Exchange (IKEv2) Protocol, for a description of the request process. Procuring such a local IP address ensures that traffic returning to the endpoint is routed to the SBC, and then tunneled back to the endpoint. Local address pools provide the source of these addresses available for temporary endpoint lease.
After address assignment from the local address pool, the endpoint retains rights to that IP address for the tunnel lifetime. Tunnels are terminated either by an INFORMATIONAL exchange, defined in Section 1.4 of RFC 7296, or by expiration of the tunnel SAs as specified by the v2-ike-life-seconds and v2-ipsec-life-seconds configuration parameters. In either case, a subsequent request for an assigned IP address may, or may not result, in the assignment of the previous IP address. However, the SBC can be configured to ensure that a prematurely terminated tunnel, resulting for example from the reset or re-boot of the remote IP peer, can be restored with that previous address. Refer to Persistent Tunnel Addressing in this chapter for operational and configuration details.
During the IKE_AUTH request phase, the IKEv2 initiator can use the Configuration payload in conjunction with either the INTERNAL_IP4_DNS or INTERNAL_IP6_DNS attribute to request the addresses of DNS providers from the SBC. In environments where authorization is performed by a RADIUS AAA server, there are two potential sources of DNS information: local SBC DNS configuration elements, and external RADIUS servers that may provide DNS information in the Access-Accept packet that concludes a successful authentication effort. The source of DNS information provided by the SBC to an IKEv2 peer is subject to user configuration.
A RADIUS source of DNS information is enabled by support for certain Microsoft vendor-specific RADIUS attributes specified in RFC2548, Microsoft Vendor-Specific RADIUS Attributes. Operationally, the SBC extracts the values of the MS-Primary-DNS-Server and MS-Secondary-DNS-Server attributes from an Access-Accept packet and returns these values to the IKEv2 initiator.
When the DNS information is from external source, the SBC installs a NAT flow (a static traffic path) that provides access to the DNS server. The NAT flow is calculated based on the location of the DNS server IP returned from RADIUS AAA server and configured realm information.
Configuration of DNS information services takes place at the local address pool and IKEv2 interface levels.
Data Flow Configuration
If you need to configure address pools, first configure data flows and then assign them to a specific local address pool. A data flow establishes a static route between a remote IKEv2 peer and a core gateway or router which provides routing services after the associated traffic exits the Oracle Communications Session Border Controller.
Local Address Pool Configuration
You configure an address pool by associating a contiguous range or ranges of IPv4 or IPv6 addresses with an existing data-flow.
Note:
An address pool can contain multiple contiguous ranges of IP addresses. However, all defined ranges must specify the same type of IP address: You cannot include IPv4 and IPv6 addresses in the same address pool.Persistent Tunnel Addressing
After address assignment from the local address pool, the endpoint retains rights to that IP address for the tunnel lifetime. Tunnels can be terminated either by an INFORMATIONAL exchange, defined in Section 1.4 of RFC 7296, or by expiration of the tunnel SAs as specified by the v2-ike-life-seconds and v2-ipsec-life-seconds parameters. In either case, a subsequent request for an assigned IP address may, or may not result, in the assignment of the previous IP address. However, the Oracle Communications Session Border Controller can be configured to ensure that a prematurely terminated tunnel can be restored with that previous address.
Tunnels are usually prematurely terminated because of re-boot or reset of the remote endpoint. In either case, the endpoint’s IKEv2 and IPsec SAs are lost and the tunnel no longer exists. From the point of view of the SBC, however, the tunnel remains live. The local IKEv2 and IPsec SAs still exist, and the tunnel remains available in an active state until the expiration of the lifetime timers. Similarly, the IP address assignment from the local address poll remains in effect until timer expiration.
When a crashed endpoint attempts to re-establish a tunnel, it can insert a Notify payload in the initial IKE_AUTH request. The Notify payload contains an INITIAL_CONTACT message that asserts a prior connection between the endpoint and the SBC. When receiving an INITIAL_CONTACT message, the SBC checks for the existence of a live tunnel with the requesting endpoint. If such a tunnel is found, the SBC stores the assigned IP address, tears down the tunnel by removing the supporting IKEv2 and IPsec SAs, and authenticates the endpoint. Assuming authentication succeeds, the SBC, retrieves the previously assigned IP address and returns it to the endpoint.
If a live tunnel is not found (meaning that the tunnel has timed out during the interval between the endpoint reset/re-boot and the new IKE_AUTH), the assertion of a prior connection is ignored, and address assignment is made from the local address pool.
You can use a global configuration option (assume-initial-contact) to enable persistent address processing with or without the reception of an INITIAL_CONTACT message. With this option enabled, all IKE_AUTH requests are processed as if they contained an INITIAL_CONTACT message.
Configuring IKEv2 Interfaces
After configuring global IKE parameters, use the procedures described in this chapter to configure and monitor IKEv2 interfaces.
IKEv2 interface configuration consists of the following steps.
- Configure IKE interface attributes
- Configure Security Associations
- Configure Security Policies
- Configure the Dead Peer Detection Protocol (optional)
- Configure the Online Certificate Status Protocol or Certificate Revocation List Support (optional)
- Configure Threshold Crossing Alerts (optional)
- Configure access control whit/black lists (optional)
EAP-based Authentication
RFC 3748, Extensible Authentication Protocol (EAP) describes a flexible and extensible framework that enables authentication services. While the RFC itself describes only a single authentication method, MD5-Challenge, the provided framework support numerous authentication methods.
The current release supports the seven EAP-based authentication methods described in the following sections. Note that for all currently supported EAP authentication methods that the actual authentication is provided by an adjacent RADIUS server. During the EAP-based authentication exchange the SBC functions as a packet relay between the authenticating client(s) and the RADIUS server.
EAP Authentication Methods
EAP supports several authentication methods.
EAP-MD5
EAP-MD5 is based on RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP). This RFC describes an authentication method that uses an agreed-upon hashing algorithm, a random challenge value, and a shared secret known only to the authenticator and the EAP peer. In the case of EAP-MD5 the hashing algorithm, which produces a 128-bit message-digest or fingerprint, is described in RFC 1321, The MD5 Message-Digest Algorithm.
Using EAP-MD5, authentication of the EAP peer is accomplished as follows.
- The authenticator issues a Challenge packet, which contains, among other fields, an Identifier field that serves to correlate message exchanges, and a Data field that contains an arbitrary challenge string.
- The peer concatenates the contents of the Identifier field, the shared-secret, and the challenge string. The peer inputs the concatenated string to the MD5 hash function, computes the 128-bit fingerprint, and returns that value to the authenticator in a Response packet.
- The authenticator performs the same calculation, and compares its results with those reported by the EAP peer.
- If the fingerprints are
identical, the authenticator issues a Success packet; otherwise the
authenticator issues a Failure packet.
Note:
EAP-MD5 does not provide for mutual authentication; the authenticator does not authenticate to the EAP peer.
EAP-MSCHAPv2
- The authenticator issues a Challenge packet, which contains, among other fields, an Identifier field that serves to correlate message exchanges, and a Data field that contains an arbitrary 16-octet challenge string.
- The peer returns a Response packet that includes the user name, a newly-generated 16-octet challenge for the authenticator, and a one-way encryption of the received challenge string, the generated challenge string, the contents of the Identifier field, and the user password.
- The authenticator performs the same calculation as was performed by the EAP peer, and compares its results with those reported by the peer. If the results are identical, the authenticator issues a Success packet which also contains a one-way encryption of the authenticator-originated challenge string, the peer-originated challenge string, the encrypted string received from the peer in the Response packet, and the user password.
- The EAP peer performs the same calculation as was performed by the authenticator, and compares its results with those reported by the authenticator. If the results are identical, the peer uses the mutually authenticated connection; otherwise, it drops the connection.
EAP-AKA
The Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) was devised by the 3GPP (3rd Generation Partnership Project), and made available to the Internet community in RFC 4187. EAP-AKA makes use of the Universal Subscriber Identity Module (USIM), an application resident on the smart card inserted in a 3G mobile phone. The USIM has access to authentication data stored on the smart card.
EAP-SIM
The EAP-SIM Protocol specifies an authentication method for GSM (Global System for Mobile Communication) subscribers. GSM is a second generation mobile standard, and still the most widely used. The authentication method is described in RFC 4186, Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identify Modules (EAP-SIM). Originally developed by the 3GPP, the EAP-SIM protocol specifies an EAP method for authentication and session key distribution using the GSM Subscriber Identity Module (SIM), a smart card installed in the GSM phone.
EAP-TLS
EAP-TLS uses a Transport Layer Security (TLS) handshake, encapsulated within the secure tunnel, to mutually authenticate client and server (or an AAA backend) with certificates. The SBC acts in EAP pass-through mode to communicate the EAP-TLS negotiation between the device and the AAA server.
EAP-TTLS
The EAP-TTLS authentication method is useful when there is no certificate-based infrastructure present for the operator to configure a certificate for each device. EAP-TTLS consists of a Tunneled Transport Layer Security (TTLS) handshake phase (similar to EAP-TLS) and a data phase. During the data phase, the client is authenticated to the server (or the client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks.
EAP-AKA
EAP-AKA' is a small revision to the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This feature allows its use in EAP in an interoperable manner. Additionally, EAP-AKA' employs SHA-256 instead of SHA-1 as the Secure Hash Algorithm.
Multiple Authentication
The Oracle Communications Session Border Controller supports multiple authentication exchanges during IKEv2 negotiation. These exchanges are defined in RFC 4739, Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol. Multiple authentication enables the SBC to engage in an initial certificate-based or shared-secret-based authentication with a remote IKEv2 peer (for example, a femtocell), followed by a subsequent EAP-AKA or EAP-SIM authentication of the remote mobile subscriber.
Multiple authentication exchanges require the use of two specific Notify payloads, MULTIPLE_AUTH_SUPPORTED and ANOTHER_AUTH_FOLLOWS (Notify message type s16404 and 16405) defined in Sections 3.1 and 3.2 of RFC 4739.
Message exchange is as follows.
Initiator (IKEv2 peer) Responder
1. HDR, SAi1, KEi, Ni --->
2. <--- HDR, SAr1, KEr, Nr, CERTREQ, N (MULTIPLE_AUTH_SUPPORTED)
3. HDR, { IDi, CERT, CERTREQ, {IDr], AUTH, SAi2, TSi, TS2
(MULTIPLE_AUTH_SUPPORTED) N (ANOTHER_AUTH_FOLLOWS) } --->
4. <--- HDR, { IDr, CERT, AUTH }
5. HDR, { IDi } --->
6. <--- HDR, { EAP (Request)}
7. HDR, { EAP (Response) } --->
8. <--- HDR, { EAP (Request)}
9. HDR, { EAP (Response) } --->
10. <--- HDR, { EAP (Success)}
11. HDR, { AUTH } --->
12. <--- HDR, { AUTH, SAr2, TSi, TSr }
In Step 2 the responder advertises support for multiple authentication via the MULTIPLE_AUTH_SUPPORTED Notification Payload.
In Step 3 the initiator advertises support for multiple authentication and, using the ANOTHER_AUTH_FOLLOWS Notification Payload, signals its readiness for such authentication.
Step 4 completes mutual certificate authentication.
In Step 5 the initiator discloses its identity.
In Step 6 the responder initiates the EAP process
In Steps 7 and 8 the initiator and responder exchange authentication information for the remote peer.
In Steps 9 and 10 the initiator and responder exchange authentication information for the mobile subscriber.
Steps 11 and 12 report successful authentication.
IPv6 Inner Tunnel Address Assignment
The Oracle Communications Session Border Controller supports the assignment of IPv6 inner tunnel addresses utilizing an external RADIUS server as the IPv6 address source. During the EAP authentication of an IPsec host, neither the SBC nor the RADIUS authentication server has any knowledge of the traffic type (IPv4 or IPv6) that the IPsec host intends to transmit through the tunnel. Consequently, the RADIUS authentication server may send both IPv4 and IPv6 attributes in the RADIUS Access-Accept message, leaving it to the SBC to select the appropriate attribute and ignore the other.
The SBC makes its decision based on the contents of the Configuration Payload received from the IPsec host. If the payload contains an INTERNAL_IP4_ADDRESS attribute, the IPv4 address received in the Access-Accept message is forwarded to the IPsec host. In a similar fashion, if the payload contains an INTERNAL_IP6_ADDRESS attribute, the IPv6 address received in the Access-Accept message is forwarded to the IPsec host.
Assignment of IPv6 addresses requires support for the following RADIUS attributes:
- Framed-IPv6-Prefix (Type 97) — also used in RADIUS accounting
- Framed-IPv6-Pool (Type 100)
Framed-IPv6-Pool, which can be returned by a RADIUS authentication server in an Access-Accept message, contains the name of an address pool that should be used by the SBC as a source of IPv6 addresses.Use of Framed-IPv6-Pool requires the pre-configuration of the identified address pool on the SBC.
EAP-only Authentication
IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, for example, one-time passwords or token cards. With EAP-SIM, EAP-AKA, EAP-AKA’, EAP-TTLS, and EAP-TLS, which provide mutual authentication and key agreement, extensible responder authentication for IKEv2 based on methods other than public key signatures can be used. This feature causes the SBC to default to EAP-only authentication without using public-key-based responder authentication unless the operator selects otherwise.
The Extensible Authentication Protocol, defined in RFC3748, is an authentication framework that supports multiple authentication mechanisms. One of the advantages of the EAP architecture is its flexibility. Rather than requiring the authenticator (for example, a wireless LAN access point) to be updated to support each new authentication method, EAP permits the use of a backend authentication server that may implement some or all authentication methods. The SBC uses a backend authentication server (for example, 3GPP AAA) and is in pass-through mode for EAP.
IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs) for IPsec Encapsulating Security Payload (ESP) and Authentication Header (AH). In addition to supporting authentication using public key signatures and shared secrets, IKEv2 also supports EAP authentication. By using EAP, IKEv2 can leverage existing authentication infrastructure and credential databases, such as Home Subscriber Server (HSS), as EAP allows users to choose a method suitable for existing credentials, and also makes separation of the IKEv2 responder (SBC) from the EAP authentication endpoint (back-end Authentication, Authorization, and Accounting (AAA) server) easier. IKEv2 specifies that these EAP methods must also be used together with responder authentication based on public key signatures. For the public key signature authentication of the SBC to be effective, a deployment of Public Key Infrastructure (PKI) is required, which has to include management of trust anchors on all supplicants. This may not realistic in WiFi calling environments, in which the security of the SBC public key is the same as the security of a self-signed certificate. Mutually authenticating EAP methods alone can provide a sufficient level of security.
Because of these reasons, the SBC now defaults to EAP-only authentication without using public-key-based responder authentication unless the operator selects otherwise by disabling the new parameter eap-only-support in the ike-interface configuration element.
Debugging IKEv2 IPsec Tunnel Establishment
The Oracle Communications Session Border Controller provides details of all IKE endpoints that establish IKEv2/IPsec tunnels. Logging can also be enabled by IP address and userid.
In a typical deployment scenario, the IP address can be the public address of a NAT device that communicates with the Oracle Communications Session Border Controller; the user-id can be the user-id of a femtocell or an IKE endpoint residing behind the NAT. The user-id can be an EAP identity exchanged during EAP authentication, or the identity contained in the IDi payload of the initial IKE_AUTH message. Typically the identity in the IDi payload is an IP address, an FQDN, or an address as defined in RFC 822, Standard for the Format of ARPA Internet Text Messages.
Enabling/Disabling Targeted Debugging
Targeted debugging is enabled by the security ike debug-logging peer-ip-userid ACLI command which takes a single string argument in the form ipAddress:userID. For example:
ORACLE# security ike debug-logging peer-ip-userid 172.16.20.1:12EDE12626719
ORACLE#
With endpoint-specific logging enabled, the log.iked, log.authd, and log.secured files are populated with data pertinent to the target endpoint only and exclude date for all other endpoints. Logging is based on an exact match of the IP address and user-id provided by the argument string.
Note:
This command is expensive and should be used to debug one or two endpoints at a time. The operating system imposes a hard limit of no more than 5 simultaneous targeted debugging sessions.Use the no form of the command to stop an existing targeted debugging session
ORACLE# security ike debug-logging peer-ip-userid 172.16.20.1:12EDE12626719 no
ORACLE#
Use the show security ike peer-endpoint-logging ACLI command to display a list of configured debug-logging sessions
ORACLE# show security ike peer-endpoint-logging
ORACLE#
IPaddress : Userid
==============
172.16.20.1:12EDE12626719
ORACLE#
High Availability Caveat
Since the security ike debug-logging peer-ip-userid command is expensive, this implementation intentionally does NOT synchronize log data on the active and standby HA devices. Consequently, in the event of a switchover from the active to the standby, no log data is available on the newly active device. To enable debug-logging on the new active device, the user should verify tunnel establishment, and then use security ike debug-logging peer-ip-userid command on the currently active member of the HA pair.
Configure an IKEv2 Interface
This section covers IKEv2 global configuration parameters, omitting IKEv1 parameters. You can override global values set in the ike-config configuration element with values set at the ike-interface level.
IPsec Security Policy Configuration
You first define ike-sainfo elements that identify cryptographic material available for Security Association negotiation, and then define interface-specific IPsec Security Policies.
IPsec SA Configuration
During the IKE_AUTH exchange, cooperating peers use the secure channel previously established by the IKE_SA_INIT exchange to negotiate child IPsec SAs to construct secure end-to-end IPsec tunnels between the peers. IKE_SA_INIT negotiations use the values provided by the ike-sainfo configuration element.
Use the following procedure to create an ike-sainfo configuration element that specifies cryptographic material used for IPsec tunnel establishment. You will later assign this ike-sainfo configuration element to an IPsec Security Policy which defines IPsec services for a specified IKEv2 interface.
Enable Tunnel Pass-Through
Use IPsec Security Policies to enable tunnel pass-through.
Pass-through IPv4 traffic via an IPv4 tunnel
- Configure IPv4 allow policy for IKE protocol traffic
- Configure IPv4 ipsec policy for media traffic
- Configure the IKEv2 IPv4 interface with an IPv4 local address pool, or
- Configure the RADIUS server to return a Framed-IP-Address and/or Framed-IP-Netmask attribute
Pass-through IPv6 traffic via an IPv6 tunnel
- Configure IPv6 allow policy for IKE protocol traffic
- Configure IPv6 ipsec policy for media traffic
- Configure the IKEv2 IPv6 interface with an IPv6local address pool, or
- Configure the RADIUS server to return a Framed-IPv6-Prefix or Framed-IPv6-Pool attribute
Pass-through IPv4 traffic via an IPv6 tunnel
- Configure IPv6 allow policy for IKE protocol traffic
- Configure IPv4 ipsec policy for media traffic
- Configure the IKEv2 IPv6 interface with an IPv4 local address pool, or
- Configure the RADIUS server to return a Framed-IP Address and/or Framed-IP-Netmask attribute
Pass-through IPv6 traffic via an IPv4 tunnel
- Configure IPv4 allow policy for IKE protocol traffic
- Configure IPv6 ipsec policy for media traffic
- Configure the IKEv2 IPv4 interface with an IPv6local address pool, or
- Configure the RADIUS server to return a Framed-IPv6-Prefix or Framed-IPv6-Pool attribute
IPSec SA Rekey on Sequence Number Overflow
The Oracle Communications Session Border Controller establishes a new IPSec security association (SA) when the counter for the outbound 32-bit Sequence Number (SN) or the 64-bit Extended Sequence Number (ESN) overflows.
The SN or ESN counter is incremented for every outbound packet. These counters can overflow when the SBC is handling packet intensive services such as video streaming or long duration calls. In accordance with RFCs 4303 and 7296, the SBC establishes new security associations, as part of rekeying, before the SN or ESN counters can roll over. It does this through the use of two parameters in the ipsec-global-config configuration element: rekey-on-sn-overflow, the default for which is enabled, and sn-rekey-threshold, which identifies the threshold for rekeying security associations as a percentage of the counter capacity and for which the default is 95.
There are four ACLI commands you can use to monitor SN and ESN counter overflows:
show datapath etc-stats ppms ipsec
- ob-sn-threshold-overflows — This counter is incremented when the SN for an outbound SA for a tunnel exceeds the user-configured threshold value.
- ob-sn-32bit-overflows — This counter is incremented when the lower 32-bits of the outbound ESN (when ESN is enabled) overflows.
- standby-ob-sn-overflows — This counter is incremented when the SN or ESN for an outbound SA for a tunnel overflows the threshold value installed on the standby node during SA installation or update on the standby system.
- ib-sn-32bit-overflows — This counter is incremented when the lower 32 bits of the inbound ESN (when ESN is enabled) overflows.
show datapath netlink show
Issuing this command shows the total number of SN overflow notifications received by the netlink layer on the host processor. The four newly-added parameters are the same as those in show datapath etc-stats ppms ipsec.
show sa stats ike
Issuing this command shows the number of times an SN overflow triggered a request for an IPsec rekey to acquire a new SA, as well as the number of times rekey requests succeeded and failed.
show security ike statistics
Issuing this command shows, with the parameter RekeyOnSNoverflow the number of times an SN overflow triggered an IPsec rekey.
Pre-Populated ARP Table
In certain topologies remote IPsec endpoints can require access to core network hosts reachable through a Oracle Communications Session Border Controller core interface. In these instances, the SBC receives the tunneled packet, and masks the received IP destination address against its own local addresses to determines if direct delivery is possible. If so, the SBC issues an ARP request to obtain the physical destination address.
This process can be expedited by pre-populating the interface-specific ARP table with a list of commonly accessed core network host reachable by that interface. With the ARP table pre-populated with IP addresses, the ARP process issues ARP requests at 5 second intervals until a response is received. Once the pre-populated IP address has been resolved, periodic ARP refreshes are used to maintain the currency of the resolution.
Configure Dead Peer Detection
Dead Peer Detection is enabled by setting the dpd-time-interval parameter to a non-zero value. DPD exchanges are asynchronous, consisting of a simple R-U-THERE and an ACK.
Certificate Revocation Lists
A Certificate Revocation List (CRL) contains a list of the serial numbers of certificates that have been revoked by the issuing Certification Authority (CA). Such issuing authorities update CRLs periodically, and make the updates lists available to subscribers. CRL updates can be deliver in either PEM (Privacy Enhanced Email) or DER (Distinguished Encoding Rules) format. PEM is base-64 encoded ASCII that provides BEGIN CERTIFICATE and END CERTIFICATE statements; DIR is a binary rendering of the PEM format. Both formats (PEM and DIR) are supported by the Oracle Communications Session Border Controller.
When authentication of remote IKEv2 peers is certificate-based, you can enable CRL usage on IKEv2 interfaces to verify certificate status.
CRL-Based Certificate Verification
This section provides instruction on using the ACLI to configure periodic retrieval of CRLs.
Configuration of CRL-based certificate verification is a three-step process.
- Specify the information and cryptological resources required to access one or more CRL sources.
- If not already done, enable CRL usage on an IKEv2 interface.
- Associate one or more CRLs with an IKEv2 interface.
Configure CRL Certificate Verification
The cert-status-profile element is a container for the information required to access a specific CRL source.
SNMP Traps
An SNMP trap is thrown, and a major alarm generated, if the Oracle Communications Session Border Controller is unable to retrieve a CRL from the server. This trap includes the server’s FQDN, assuming that the FQDN has been identified during the configuration process, the server’s IP address, the reason for the failure, and the time of the last successful CRL retrieval, with the time expressed as the number of seconds since midnight January 1, 1970.
A second SNMP trap is thrown when the SBC successfully retrieves a CRL. This trap includes the server’s FQDN, assuming that the FQDN has been identified during the configuration process, and the server’s IP address. The issue of this trap also clears any associated major alarm.
Configuring Manual CRL Updates
The ACLI provides the ability to perform an immediate manual refresh of one or more CRLs.
Use the following command to refresh a single CRL.
ORACLE# load-crl local-file <fileName>
where <fileName> is a remote filepath specified by the crl-list attribute.
Use the following command to refresh all CRLs.
ORACLE# load-crl local-file all
Use the following command to refresh all CRLs from a specific CRL source.
ORACLE# load-crl cert-status-profile <certStatusProfileName>
where <certStatusProfileName> references the certificate-status-profile configuration element that contains the CRL source IP address or FQDN.
Use the following command to refresh all CRLs.
ORACLE# load-crl cert-status-profile all
Online Certificate Status Protocol
The Online Certificate Status Protocol (OCSP) enables users to determine the revocation state of a specific certificate. Because OCSP ensures access to the freshest CRL, it can provide a more timely source of revocation information than is possible with dynamically or manually loaded CRLs. Guaranteed access to the most recent CRL, however, comes at the expense of increased traffic: a single request/response exchange for each revocation check.
If the OCSP responder returns a status of good, the certificate is accepted and authentication succeeds. If the OCSP responder returns a status other than good, the certificate is rejected and authentication fails.
Certificate status is reported as
- good—which indicates a positive response to the status inquiry. At a minimum, a positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate’s validity interval.
- revoked—which indicates a negative response to the status inquiry. The certificate has been revoked, either permanently or temporarily.
- unknown—which indicates a negative response to the status inquiry. The responder cannot identify the certificate.
When authentication of remote IKEv2 peers is certificate-based, you can enable OCSP on IKEv2 interfaces to verify certificate status.
OCSP-Based Certificate Verification
The following sections provides instruction on using the ACLI to configure OCSP-based certificate verification.
Configuration of OCSP-based certificate verification is a three-step process.
- Specify the information and cryptological resources required to access one or more OSCP responders.
- Enable OCSP on an IKEv2 interface.
- Associate one or more OCSP responders with an IKEv2 interface.
Threat Protection
IKEv2 threat protection is composed of:
- IKEv2 DDoS control
- White and Black list access controls
- IP-header based firewalls
IKEv2-Based DDoS Attacks
Given its usual location at the network edge, and the two stage negotiation process required for the establishment of IPsec tunnels, the Oracle Communications Session Border Controller can be a target of IKEv2-based DDoS (distributed denial of service) attacks. Such attacks, which seek to overwhelm or monopolize system resources to the detriment of the gateway’s functionality, can take several forms including:
- prolonging/failing to complete negotiation of the IKEv2 Security Association (SA)
- prolonging/failing to complete negotiation of the IPsec SA
- excessive renegotiation/rekeying of an established IKEv2 SA
- excessive renegotiation/rekeying of an established IPsec SA
- sabotaging the IKEv2 negotiation by failing to present a valid cookie when required to do so
- sabotaging the IKEv2 negotiation by failing to present valid credentials when required to do so
The SBC provides protection against DDoS attacks by monitoring IKEv2 signaling traffic from remote endpoints (defined by an IP address:UDP port pair). All endpoints start in the allowed state, meaning that IKEv2 signaling received from the endpoint is accepted as valid by the SBC. A group of policing parameters, and associated counters, provide protection against DDoS attacks by monitoring IKEv2 signaling from individual endpoints. The SBC maintains a set of counters for each endpoint. The counters record instances of suspect traffic, which may indicate malicious intent, and periodically compare endpoint-specific traffic counts to threshold values established by the policing parameters. If endpoint counts meet or exceed threshold values, the SBC places the endpoint in the deny state, and, if they exist, tears down the IKEv2 SA and IPsec SA associated with the endpoint. While in the deny state, the endpoint is quarantined and refused all access to the IKEv2 interface. The endpoint remains quarantined until the expiration of a pre-set timer. At timer expiration, the endpoint is transitioned to the allowed state, and granted IKEv2 interface access.
Configuration of IKEv2 DDOS protection consists of the following steps.
- Configure one or more IKEv2
Access Control Templates.
An IKEv2 Access Control Template enables protection against a DDOS attack, and provides a set of configurable timers and policing parameters used to monitor and squelch suspect IKEv2 traffic.
Two parameters set user-configurable timers; tolerance-window sets the interval between periodic checks of suspect traffic counts, and deny-period specifies the duration of the deny state.
Additional parameters (pre-ipsec-invalid-threshold, pre-ipsec-maximum-threshold, invalid-cookie-threshold, post-ipsec-invalid-threshold, pre-ipsec-maximum-threshold, and auth-failure-threshold) set threshold counts for suspect traffic that may be malicious in nature.
- Assign a template to an
IKEv2 interface.
Assignment of a template to an IKEv2 interface enables protection against a DDOS attack on that specific interface.
Constructing an IKEv2 Access Control Template
Use the following procedure to construct an IKEv2 Access Control Template.
Assigning an Access Control Template to an IKEv2 Interface
Use the following procedure to assign an IKEv2 Access Control Template to an IKEv2 interface. The template assignment enables IKEv2 DDOS protection on the interface.
Configuring White and Black Lists with Access Control
The SBC supports IKEv2 access-control white lists that permit authentication only for a provisioned list of IMSI prefixes or MAC addresses. The SBC also supports black lists that deny authentication to a provisioned list of IMSI prefixes or MAC addresses.
Configuring White Lists
Use the procedures described in this section only when authentication is performed by the EAP-SIM protocol. This section can be ignored when the Oracle Communications Session Border Controller employs any other authentication method.
EAP-SIM Protocol Overview
The EAP-SIM Protocol is described in RFC 4186, Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identify Modules (EAP-SIM). Originally developed by the 3GPP (3rd Generation Partnership Project), the EAP-SIM protocol provides for mutual authentication between the authenticator (a RADIUS server) and a GSM subscriber.
Within the EAP-SIM framework the GSM subscriber identifies itself with its International Mobile Subscriber Identity (IMSI), a digit string providing a globally unique identity for the subscriber’s device. The IMSI is stored on a Subscriber Identity Module (SIM) installed in the GSM phone.
The IMSI is usually a 15-digit string that takes the following form:
<MCC><MNC><MSIN>
- MCC (Mobile Country Code) prefix — 3 digits that uniquely identify the carrier’s residence, not the subscriber’s current location
- MNC (Mobile Network Code) prefix — 2 or 3 digits that identify the carrier (the concatenation of the MCC and MNC prefixes provide unambiguous identification of the carrier network)
- MSIN (Mobile Station Identification Number) — the remaining digits identify the specific device within the carrier’s network
IMSI/MAC Filtering
With EAP-SIM protocol in use, authentication is accomplished by a RADIUS server. Using the Wm interface, the Oracle Communications Session Border Controller passes the received IMSI identity to the RADIUS server. In order to minimize server processing, the SBC provides users with the optional ability to compile IMSI prefix white lists that filter identities presented for RADIUS authentication. White lists are inclusive in that only those identities matching list contents are granted RADIUS access; non-matching identities are summarily rejected by the SBC. The white lists contain numeric strings or simple regular expressions that identify blocks of subscribers eligible for access to the RADIUS server.
These strings are interpreted as either an IMSI prefix or as a MAC address. White lists now contain either IMSI or MAC identifiers. Identifiers are constructed using the digits 0 through 9 , any hexadecimal digit, and the ^ wild-card character, which specifies any single base-10 or base-16 digit. Each identifier supports one or more subscribers eligible for authentication.
- 744 matches the country of Paraguay
- 74401 matches a specific Paraguayan carrier (Hola Paraguay S.A.)
- 7440^ matches all current Paraguayan carriers (74401, 74402, 74404, and 74405)
Configure IMSI/MAC White Lists
The ike-access-control configuration element defines a white list that filters IMSI or MAC identities presented by remote endpoints during the authentication process. Only those identities matching the literal or regular expressions contained within the white list are forwarded via the Wm interface to a RADIUS server for authentication.
Configure Black Lists
A black list is provisioned with a femtocell's EAP identity,
taking the form
<MAC ID>@cellID.serviceProvider.com
and denying
authentication for such femtocells trying to establish IKE/IPsec tunnels. Black
lists are only applicable for femtocell clients doing EAP authentication to the
SBC and are not
applicable for clients doing password-based or certificate-based
authentication.
White List/Black List Interaction
White lists and black lists may or may not be assigned to the IKEv2 interfaces. The following rules are used to support implementation of both list types.
Viewing Security IKE Statistics
Via the show security ike statistics ACLI command, you can view statistics derived from the IKEAuthIDError and BlacklistIKEAuthIDError counters, containing the number of authentication denials due to both white and black list filtering.
For detailed information on the show security ike statistics ACLI command, see The ACLI Reference Guide.
Stateless Firewall
The SBC provides enhanced security-policy-based filters that can be applied to data packets coming through IPSec tunnels on the protected interfaces, and to non-IPSec packets on the trusted interfaces. These filters evaluate only the IP header layer, and treat each individual packet as a discrete event. As such, the functionality they provide can be compared to that provided by a stateless firewall.
Available filters are discussed in the following sections.
ICMP Filtering
Internet Control Message Protocol (ICMP) messages can be filtered based on message Type and associated message Codes.
ICMP Policy Configuration
Use the following procedure to define security-policy-based filtering of ICMP packets. This sample policy discards ICMP message type 0, Echo Reply, code 0, Net Unreachable.
SCTP Filters
Internet Control Message Protocol (ICMP) messages can be filtered based on Payload Protocol Identifiers.
SCTP Policy Configuration
Use the following procedure to define security-policy-based filtering of SCTP packets. This sample policy allows SCTP, Payload Protocol Identifier 34, Diameter in SCTP DATA chunk.
Source Routing Packets
The SBC can unconditionally discard all source routed packets at the global level. Source routed packets are identified by the presence of either a Loose Source Route/Record (LSRR) or a Strict Source Route/Record (SSRR) option within the IP header Options header.
Both options have the potential to mask malicious intent. An attacker can use the specified routes to hide the true source of a packet, or to gain access to a protected network. Consequently, such packets are often dropped upon network entry.
Use the following procedure to unconditionally discard all source routed packets.
Fragmented Packets
The SBC can unconditionally discard all inbound fragmented Encapsulating Security Protocol (ESP) packets using a global option. Refer to Figure 3, ESP Transport Mode, and Figure 5, ESP Tunnel Mode, for ESP details.
Upon reception, the SG re-assembles such packets and then decrypts the re-assembled packet. After decryption, if the decrypted packet is still a fragment, the new option mandates that the packet fragment be discarded in light of the SG’s inability to do a proper policy check on an incomplete message.
Use the following procedure to unconditionally discard all fragmented ESP packets.
Threshold Crossing Alert Configuration
Threshold Crossing Alerts (TCAs) monitor specific MIB variables or counters, and generate SNMP traps when object values cross defined thresholds. Three types of TCAs are supported:
- IKE Failed Authentication (monitors IKE negotiation counters)
- IPsec Tunnel Removal (monitors IPsec tunnel counters)
- Dead Peer Detections (monitors DPD protocol counters)
Threshold levels, listed in order of increasing importance are clear, minor, major, and critical. Each threshold level is user-configurable and is accompanied by a associated reset-counter, also user-configurable, which prevents the issue of extraneous SNMP traps when a counter is bouncing across threshold values.
A threshold crossing event occurs when the associated counter value rises above the next-highest threshold value, or when the associated counter value falls below the next-lowest reset-threshold value. An SNMP trap, raising the alert level, is generated as soon as the counter value exceeds the next-highest threshold. An SNMP trap, lowering the alert level, occurs only during a check period when the TCA examines all counter values. Such check periods occur at 100 second intervals.
The following scenario illustrates TCA operations. The sample TCA, ike-tca-group, monitors the count of dead IKEv2 peers. Threshold and reset values are shown. A minor alarm threshold and its associated reset threshold have not been configured.
nameike-tca-group
tca-typeike-dpd
critical100
reset-critical90
major80
reset-major50
minor0
reset-minor0
t=time
t=0 ike-dpd counter= 30 ike-dpd alert level=clear
t=1 ike-dpd counter= 60 ike-dpd alert level=clear
t=2 ike-dpd counter= 80 ike-dpd alert level=major trap sent
t=3 ike-dpd counter= 95 ike-dpd alert level=major
t=4 ike-dpd counter=100 ike-dpd alert level=critical trap sent
t=5 ike-dpd counter=120 ike-dpd alert level=critical
t=6 ike-dpd counter= 99 ike-dpd alert level=critical
t=7 ike-dpd counter= 90 ike-dpd alert level=major trap sent
t=8 ike-dpd counter= 60 ike-dpd alert level=major
t=9 ike-dpd counter= 0 ike-dpd alert level=clear trap sent
Use the following procedure to configure TCAs.
IKEv2 Interface Management
The following two sections provide details on available counters that gather usage and error data related to IKEv2/IPsec operations on the Oracle Communications Session Border Controller.
The first section, IKEv2 Protocol Operations, describes a series of 32-bit counters that report interface-specific data on various protocol transactions. Protocol operations counter values are available with SNMP, through the ACLI show security ike statistics command, and can also be obtained by subscription to the ike_stats HDR group.
The second section, IKEv2 Negotiation Errors, describes a series of 32-bit counters that report interface-specific errors encountered during IKEv2 negotiations. Negotiation errors counter values are also available with SNMP, through the ACLI show security ike statistics command, and can also be obtained by subscription to the ike-stats HDR group.
The third section, RADIUS Protocol Operations, describes a series of 32-bit counters that report RADIUS-server-specific data. RADIUS protocol operations counter values are also available with SNMP, through the ACLI show radius command, and can also be obtained by subscription to the radius-stats HDR group.
The final section, Diameter Protocol Operations, describes a series of 32-bit counters that report Diameter-server-specific data. Diameter protocol operations counter values are also available with SNMP, and can also be obtained by subscription to the diameter-stats HDR group.
IKEv2 Protocol Operations
Note:
The range for all 32-bit counters is 0 to 4294967295.Name | Description | Type | SNMP MIB Ending |
---|---|---|---|
Current Child SA Pairs | The number of current child IPsec SA pairs on the interface. As each IPsec tunnel requires two unidirectional SAs, this number equals the current number of tunnels on the interface. Note that this count is available through both an ACLI show command and an SNMP GET operation. | gauge | .33 |
Maximum Child SA Pairs | The largest number of child IPsec SA pairs on the interface since this counter was last reset. As each IPsec tunnel requires a single SA pair, this value equates to the largest number of tunnels on the interface. | gauge | |
Last Reset Timestamp | The time that this interface was last reset -- expressed as a UNIX timestamp containing the number of seconds since January 1, 1970. | UNIX timestamp | |
Child SA Request | The number of requests to add a child SA pair that were received on the interface. These requests include IPsec SA rekey requests. | counter | .1 |
Child SA Success | The number of requests to add a child SA pair that were successfully completed on the interface. These successes include new children created by IPsec SA rekeys. | counter | .2 |
Child SA Failure | The number of requests to add a child SA pair that were not successfully completed on the interface. These failures include unsuccessful IPsec SA rekeys. | counter | .3 |
Child SA Delete Requests | The number of requests to delete a child SA pair that were received on the interface. These requests include deletion requests associated with IPsec SA rekeys. | counter | .4 |
Child SA Delete Success | The number of requests to delete a child SA pair that were successfully completed on the interface. These successes include children deleted by IPsec SA rekeys. | counter | .5 |
Child SA Delete Failure | The number of requests to delete a child SA pair that were not successfully completed on the interface. These failures include unsuccessful deletions associated IPsec SA rekeys. | counter | .6 |
Child SA Rekey | The number of child IPsec rekey exchanges transacted on the interface. | counter | .7 |
Initial Child SA Establishment | The number of initial child SA pair establishments, in other words, the number of successful IKE_AUTH exchanges transacted on the interface. | counter | .8 |
DPD Received Port Change | The number of DPD messages received on the interface that contained a port change from the previously received message. The port change indicates that the IKEv2 has moved to another port, or that an intervening NAT device has changed port mapping. These actions do not impact SA functions. | counter | .9 |
DPD Received IP Change | The number of DPD messages received on the interface that contained an IP address change from the previously received message. | counter | .10 |
DPD Response Received | The number of DPD ACK responses received on the interface. An ACK is sent by an IKEv2 peer in response to an R-U-THERE issued by the Oracle Communications Session Border Controller. A successful R-U-THERE/ACK exchange establishes availability on the remote IKEv2 peer. | counter | .11 |
DPD Response Not Received | The number of R-U-THERE messages transmitted on the interface that were not acknowledged within the DPD allowed interval. | counter | .12 |
DPD Received | The number of all DPD protocol messages received on the interface. | counter | .13 |
DPD Retransmitted | The number of R-U-THERE messages that were re-transmitted because the original R-U-THERE message was not acknowledged. | counter | .14 |
DPD Sent | The number of R-U-THERE messages that were sent across the interface, to include retransmitals. | counter | .15 |
IKE SA Packets Sent | The number of IKEv2 SA packets sent across the interface. | counter | .16 |
IKE SA Packets Received | The number of IKEv2 SA packets received across the interface. | counter | .17 |
IKE SA Packets Dropped | The number of IKEv2 SA packets dropped by the interface. | counter | .18 |
Authentication Failures | The number of authentication failures that occurred after the purported identity of the remote IKEv2 peer was ascertained. | counter | .19 |
IKE Message Errors | The number of otherwise uncharacterized IKEv2 message errors. | counter | .20 |
Authentication ID Errors | The number of errors that occurred during the identification stage of the authentication process. | counter | .21 |
Certificate Status Requests | The number of certificate status requests sent across the interface to an OCSP responder. | counter | .22 |
Certificate Status Success | The total number of OCSP successes, that is the number of OCSP requests that generated a good status from an OCSP responder. | counter | .23 |
Certificate Status Fail | The total number of OCSP failures, to include unacknowledged OCSP requests and those requests that generated a revoked or unknown response from an OCSP responder. | counter | .24 |
DDoS Sent | The number of suspicious, and possibly malicious, endpoints reported by the interface-specific DDoS process (if configured as described in the IKEv2 DDoS Protection section of the Oracle Communications Session Border Controller Essentials guide). | counter | .25 |
DDoS Received | The number of suspicious, and possibly malicious, endpoints reported by statically provisioned deny lists (as described in SIP Signaling Services and Security chapters of the ACLI Configuration Guide). | counter | .26 |
IKE Message Retransmissions | The total number of IKEv2 message re-transmissions. | counter | .27 |
SA Init Messages Received | The total number of IKEv2 message re-transmissions. | counter | .28 |
SA Init Message Sent | The total number of IKEv2 message re-transmissions. | counter | .29 |
SA Establishment Attempts | The total number of IKEv2 message re-transmissions. | counter | .30 |
SA Establishment Success | The total number of IKEv2 SA successfully established on the IKEv2 interface. | counter | .31 |
Tunnel Rate | Specifies the tunnel establishment rate, in terms of tunnels created per second. Note that this count is available through both an ACLI show command and an SNMP GET operation. | gauge | .32 |
IKEv2 Negotiation Errors
The SNMP MIB is formed by appending the value in the SNMP MIB Ending column to 1.3.6.1.4.1.9148.3.9.1.3.X (apSecurityIkeInterfaceStatsEntry), where X specifies the interface index. For example, the SNMP MIB for the CPU Overload Errors is 1.3.6.1.4.1.9148.3.9.1.3.X.3, where X specifies the interface index.
Name | Description | SNMP MIB Ending |
---|---|---|
CPU Overload Errors | The number of IKEv2 requests that were rejected because of CPU load constraints. | .3 |
Init Cookie Errors | The number of all IKEv2 exchanges that failed because of faulty Security Parameter Index (SPI) values. SPIs provide a local SA identifier and are exchanged between IKEv2 peers in the common IKEv2 header and in Notify Payloads. | .4 |
Auth Errors | The number of failed IKE_AUTH exchanges, regardless of the specific reason for failure. | .5 |
EAP Access Request Errors | The number of authentication failures that occur ed during the EAP access phase. | .6 |
EAP Access Challenge Errors | The number of authentication failures that occur ed during the EAP challenge phase. | .7 |
TS Errors | The number of CREATE_CHILD_SA exchanges that failed because of faulty TS payload contents, or failure on the part of the remote peers to negotiate the offered traffic selectors. | .8 |
CP Errors | The number of IKE_AUTH and/or CREATE_CHILD_SA exchanges that failed because of faulty, unsupported, or unknown Configuration Payload contents. | .9 |
IKE Errors | The number of IKE_SA_INIT and/or CREATE_CHILD_SA exchanges that failed because of faulty, unsupported, or unknown Key Exchange Payload contents. | .10 |
Proposal Errors | The number of failed negotiations that resulted from the inability to reconcile crytographic proposals contained in the Security Association Payloads exchanged by IKEv2 peers. Security Association Payloads are exchanged during the IKE_SA_INIT, IKE_AUTH, and CREATE_CHILD_SA stages. | .11 |
Syntax Errors | The number of failed negotiations, of any type, resulting from otherwise uncharacterized errors. | .12 |
Critical Payload Errors | The number of failed negotiations that resulted from the presence of a Critical flag in a payload that could not be parsed, or was not supported. IKEv2 adds a critical flag to each payload header for further flexibility for forward compatibility. If the critical flag is set and the payload type is unrecognized, the message must be rejected and the response to the IKE request containing that payload MUST include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an unsupported critical payload was included. If the critical flag is not set and the payload type is unsupported, that payload must be ignored. | .13 |
RADIUS Protocol Operations
The SNMP MIB is formed by appending the value in the SNMP MIB Ending column to 1.3.6.1.4.1.9148.3.18.1.1.1 (aapRadiusServerStatsEntry). For example, the SNMP MIB for the Server Roundtrip Time is 1.3.6.1.4.1.9148.3.18.1.1.1.3.
Name | Description | SNMP MIB Ending |
---|---|---|
Server Roundtrip Time | Contains the average round trip time for a response from this RADIUS server. | .3 |
Server Malformed Access Response | Contains the number of malformed access responses received on this RADIUS server. | .4 |
Server Access Requests | Contains the number of access requests received on this RADIUS server. | .5 |
Server Disconnect Requests | Contains the number of disconnect requests received on this RADIUS server. | .6 |
Server Disconnect ACKS | Contains the number of acknowledged disconnects on this RADIUS server. | .7 |
Server Disconnect NACKS | Contains the number of unacknowledged disconnects on this RADIUS server. | .8 |
Server Bad Authenticators | Contains the number of authentication rejections on this RADIUS server. | .9 |
Server Access Retransmissions | Contains the number of access retransmitals on this RADIUS server. | .10 |
Server Access Accepts | Contains the number of successful authentications on this RADIUS server. | .11 |
Server Timeouts | Contains the number of Response timeouts on this RADIUS server. | .12 |
Server Access Rejects | Contains the number of unsuccessful authentications on this RADIUS server. | .13 |
Server Unknown PDUTypes | Contains the number or unknown/unreadable PDUs received by this RADIUS server. | .14 |
Server Access Challenges | Contains the number of Access Challenges on this RADIUS server. | .15 |
Diameter Protocol Operations
The SNMP MIB is formed by appending the value in the SNMP MIB Ending column to 1.3.6.1.4.1.9148.3.13.1.1.2.2.X (apDiamInterfaceStatsTable), where X specifies the diameter server index. For example, the SNMP MIB for the Diameter Messages Sent is 1.3.6.1.4.1.9148.3.13.1.1.2.2.X.3, where X specifies the diameter server index.
Name | Description | SNMP MIB Ending |
---|---|---|
Diameter Messages Sent | Contains the number of messages sent by this Diameter server. | .3 |
Diameter Messages Sent Failed | Contains the number of unacknowledged messages sent by this Diameter server. | .4 |
Diameter Messages Resent | Contains the number of messages re-transmitted to this Diameter server. | .5 |
Diameter Messages Received | Contains the number of messages received by this Diameter server. | .6 |
Diameter Messages Processed | Contains the number of messages processed by this Diameter server. | .7 |
Diameter Connection Timeouts | Contains the number of connection timeouts on the Diameter server. | .8 |
Diameter BadState Drops | Contains the number of packets dropped because of faulty state on the Diameter server. | .9 |
Diameter BadType Drops | Contains the number of packets dropped because of faulty type on the Diameter server. | .10 |
Diameter BadID Drops | Contains the number of packets dropped because of faulty ID on the Diameter server. | .11 |
Diameter AuthFail Drops | Contains the number of failed authentications on the Diameter server. | .12 |
Diameter Invalid Peer Messages | Contains the number of client messages that could not be parsed on the Diameter server. | .13 |
ACLI Show Commands
ACLI show commands
- display and reset IKEv2 performance and error counters
- display IKEv2 SA data
- display IKEv2 TCA data
Performance and Error Counters
Three ACLI commands display and reset IKEv2 performance and error counters.
Use the show security command to display performance and error counters for a specified IKEv2 interface, or for all IKEv2 interfaces.
ORACLE# show security 192.169.204.15
with a specified interface, displays performance and error counters for the target interface
ORACLE# show security all
with all, displays performance and error counters for all IKEv2 interfaces
Use the reset ike-stats command to reset (set to 0) performance and error counters for a specified IKEv2 interface, or for all IKEv2 interfaces.
ORACLE# reset ike-stats 192.169.204.15
with a specified interface, resets performance and error counters for the target interface
ORACLE# reset ike-stats all
with all, resets performance and error counters for all IKEv2 interfaces
Use the reset ike-mib command to reset (set to 0) MIB-based error counters for all IKEv2 interfaces.
ORACLE# reset ike-mib
re-sets the MIB-based error counters for all IKEv2 interfaces
IKEv2 and Child SAs
Use the show security command with optional arguments to display IKEv2 and child SA information to include:
- IP address and port of remote end-point
- intervening NAT device (yes | no)
- local IP address
- tunnel state (up | down)
- initiator cookie
- responder cookie
- remote inner (tunnel) IP address
- incoming/outgoing Security Parameter Indexes (SPI) of the child SA
ORACLE# show security sad ike-interface 192.169.204.15
with a specified interface address, displays SA information for a single IKEv2 interface
ORACLE# show security sad ike-interface all
with all, displays SA information for all IKEv2 interfaces
ORACLE# show security sad ike-interface all
Displaying the total (4321) number of entries may take long and could affect system performance.
Continue? [y/n]?: y
Peer: 6.0.0.36:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x23e71b73d5a10c58[I] 0xd2017a6fb84a4fa6[R]
Child Peer IP: 101.0.0.36:0 Child SPI: 4236760138[I] 1721373661[O]
Peer: 6.0.0.28:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0xf64d031d32525730[I] 0xcea2d5ae3c91050f[R]
Child Peer IP: 101.0.0.28:0 Child SPI: 3632387333[I] 1421117246[O]
Peer: 6.0.0.9:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x84ec95a1cd0a4c5d[I] 0x1b61b385c4e627b4[R]
Child Peer IP: 101.0.0.9:0 Child SPI: 2432742837[I] 3872387177[O]
Peer: 6.0.0.25:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x541b2651e88c9368[I] 0xdc393a61af6dc909[R]
Child Peer IP: 101.0.0.25:0 Child SPI: 785656546[I] 148357787[O]
Peer: 6.0.0.27:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x3ba43c5c685e37e6[I] 0x7bfa6f0781dce1a8[R]
Child Peer IP: 101.0.0.27:0 Child SPI: 767765646[I] 3797275291[O]
Peer: 6.0.0.22:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x925e540ecbd58dbb[I] 0x7e1101371a5a5823[R]
Child Peer IP: 101.0.0.22:0 Child SPI: 787745714[I] 876969665[O]
Peer: 6.0.0.2:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0xda0f568684ba5e2c[I] 0x74c533da2fd29901[R]
Child Peer IP: 101.0.0.2:0 Child SPI: 3884481109[I] 1862217459[O]
Peer: 6.0.0.7:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x6166bac4438f3ca7[I] 0x71d1049a0f8520f4[R]
Child Peer IP: 101.0.0.7:0 Child SPI: 2798332266[I] 2789214337[O]
Peer: 6.0.0.15:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x0e060701115069bf[I] 0x2e69adbf15438000[R]
Child Peer IP: 101.0.0.15:0 Child SPI: 713005957[I] 1985608540[O]
Continue? [y/n]?: y
...
...
Use show security with the peer address obtained by the previous command to display more detailed information regarding a specific tunnel to include:
- IKE version
- Diffie Hellman group
- the IKE SA hash algorithm
- the IKE SA message authentication code algorithm
- the IKE SA encryption algorithm
- seconds since SA creation
- SA lifetime in seconds
- remaining lifetime in seconds
- IPsec operational mode (tunnel | transport)
- IPsec security protocol (AH |ESP)
- IPsec authentication protocol (SHA1 | MD5 | any)
- IPsec encryption protocol (AES | 3DES | null| any)
ORACLE# show security sad ike-interface <ipAddress> peer <ipAddress>
ORACLE# show security sad ike-interface 172.16.101.2 peer 6.0.0.36:500
IKE SA:
IKE Version : 2
Tunnel State : Up
Last Response [Seconds] : 212
AAA Identity :
NAT : No
IP Addresses [IP:Port]
Peer : 6.0.0.36:500
Server Instance : 172.16.101.2:500
Cookies
Initiator : 0x23e71b73d5a10c58
Responder : 0xd2017a6fb84a4fa6
Algorithms
DH Group : 2
Hash : HMAC-SHA1
MAC : SHA1-96
Cipher : 3DES
SA Times [Seconds]
Creation : 141
Expiry : 86400
Remaining : 86188
IPSec SA:
IP Addresses [IP:Port]
Destination : 101.0.0.36:0
Source : 172.16.101.2:0
SPI
Outbound : 1721373661
Inbound : 4236760138
Algorithms
Mode : TUNNEL
Protocol : ESP
Authentication : SHA1
Encryption : AES
Traffic Selectors [Start IP - End IP]
Destination : 101.0.0.36 - 101.0.0.36
Source : 172.16.101.2 - 172.16.101.2
TCA Counters
An ACLI command is provided to display TCA information.
ORACLE# show security ike threshold-crossing-alert <ipAddress> || all
with a specified IPv4/IPv6 interface address, displays TCA information for the specified IKEv2 interface, otherwise displays TCA information for all IKEv2 interfaces
ORACLE# show security ike threshold-crossing-alert all
ORACLE# show security ike threshold-crossing-alert all
IKE Threshold Crossing Alerts
tca-type: ike-auth-failure
reset reset reset
critical critical major major minor minor
---------- ---------- ---------- ---------- ---------- ----------
40 30 25 24 12 1
current value:
Window Total Maximum
0 0 0
current level: clear
tca-type: ipsec-tunnel-removal
reset reset reset
critical critical major major minor minor
---------- ---------- ---------- ---------- ---------- ----------
0 0 10 5 0 0
current value:
Window Total Maximum
0 0 0
current level: clear
Historical Data Records
Various statistical counts are available as comma separated values (CSV) Historical Data Record (HDR) files. HDR files are specified and pushed to an accounting server as described in the Overview chapter of the 4000 C-Series Historical Data Recording (HDR) Resource Guide.
IKEv2 Interface HDR
CSV header fields for IKEv2 Interface HDRs are listed below.
IKEv2 Interface HDR | Type |
---|---|
TimeStamp | Integer |
Interface | IP Address |
Current Child SA Pairs | Counter |
Maximum Child SA Pairs | Counter |
Last Reset TimeStamp | Integer |
Child SA Requests | Counter |
Child SA Success | Counter |
Child SA Failure | Counter |
Child SA Delete Request | Counter |
Child SA Delete Success | Counter |
Child SA Delete Failure | Counter |
Child SA Rekey | Counter |
Initial Child SA Establishment | Counter |
DPD Received Port Change | Counter |
DPD Received IP Change | Counter |
DPD Response Received | Counter |
DPD Response Not Received | Counter |
DPD Received | Counter |
DPD Retransmitted | Counter |
DPD Sent | Counter |
IKE SA Packets Sent | Counter |
IKE SA Packets Received | Counter |
IKE SA Packets Dropped | Counter |
Authentication Failures | Counter |
IKE Message Errors | Counter |
Authentication ID Errors | Counter |
Certificate Status Requests | Counter |
Certificate Status Success | Counter |
Certificate Status Fail | Counter |
DDoS Sent | Counter |
DDoS Received | Counter |
IKE Message Retransmissions | Counter |
Tunnel Rate | Counter |
Child SA Pair | Guage |
IKE SA INIT Messages Received | Counter |
IKE SA INIT Messages Sent | Counter |
IKE SA Establishment Attempts | Counter |
IKE SA Establishment Success | Counter |
IKE CPU Overload Error | Counter |
IKE init Cookie Error | Counter |
IKE EapAccessRequestError | Counter |
IKE EapAccessChallengeError | Counter |
IKE TS Error | Counter |
IKE CP Error | Counter |
IKE KE Error | Counter |
IKE Proposal Error | Counter |
IKE Syntax Error | Counter |
IKE Critica; Payload Error | Counter |
RADIUS HDR
CSV header fields for RADIUS HDRs are listed below.
IKEv2 Interface HDR | Type |
---|---|
Time Stamp | Integer |
RADIUS Sever IP Address | IP Address |
RADIUS Server Port | Port Address |
Round Trip Time | Counter |
Malformed Access Response | Counter |
Access Requests | Counter |
Disconnect Requests | Counter |
Disconnect ACKs | Counter |
Bad Authenticators | Counter |
Access Retransmissions | Counter |
Access Accepts | Counter |
Timeouts | Counter |
Access Rejects | Counter |
Unknown PDU Types | Counter |
Access Challenges | Counter |
Diameter HDR
CSV header fields for Diameter HDRs are listed below.
IKEv2 Interface HDR | Type |
---|---|
Time Stamp | Integer |
Diameter Sever IP Address | IP Address |
Diameter Server Port | Port Address |
Messages Sent | Counter |
Messages Sent Failed | Counter |
Messages Resent | Counter |
Messages Received | Counter |
Messages Processed | Counter |
Connection Timeouts | Counter |
Bad State Drops | Counter |
Bad Type Drops | Counter |
Bad ID Drops | Counter |
Auth Failed Drops | Counter |
Invalid Peer Messages | Counter |