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.

IKEv1 Global Configuration

To configure global IKEv1 parameters:

Note:

DPD only works with IKEv2.

From superuser mode, use the following command sequence to access ike-config configuration mode. While in this mode, you configure global IKEv1 configuration parameters.
```
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-config
ORACLE(ike-config)#
```
Use the ike-version parameter to specify IKEv1.

Use 1 to specify IKEv1 operations.
Use the log-level parameter to specify the contents of the IKEv1 log.

Events are listed below in descending order of criticality.
- emergency (most critical)
- critical
- major
- minor
- warning
- notice
- info (least critical — the default)
- trace (test/debug, not used in production environments)
- debug (test/debug, not used in production environments)
- detail (test/debug, not used in production environments)
In the absence of an explicitly configured value, the default value of info is used.
Use the optional udp-port parameter to specify the port monitored for IKEv1 protocol traffic.

In the absence of an explicitly configured value, the default port number of 500 is used.
Use the optional negotiation-timeout parameter to specify the maximum interval (in seconds) between Diffie-Hellman message exchanges.

In the absence of an explicitly configured value, the default specifies a 15 second timeout value.
Use the optional event-timeout parameter to specify the maximum time (in seconds) allowed for the duration of an IKEv1 event, defined as the successful establishment of an IKE or IPsec Security Association (SA).

In the absence of an explicitly configured value, the default specifies a 60 second time span.
Use the optional phase1-mode parameter to specify the IKE Phase 1 exchange mode.

During Phase 1 the IKE initiator and responder establish the IKE SA, using one of two available methods.

main mode — (the default) is more verbose, but provides greater security in that it does not reveal the identity of the IKE peers. Main mode requires six messages (3 requests and corresponding responses) to (1) negotiate the IKE SA, (2) perform a Diffie-Hellman exchange of cryptographic material, and (3) authenticate the remote peer.

aggressive mode — is less verbose (requiring only three messages), but less secure in providing no identity protection, and less flexible in IKE SA negotiation.

In the absence of an explicitly configured value, the default (main mode) is used.
Use the optional phase1-dh-mode parameter to specify the Diffie-Hellman Group used during IKE Phase 1 negotiation.

dh-group1 — as initiator, propose Diffie-Hellman group 1 (768-bit primes, less secure)

dh-group2 — as initiator, propose Diffie-Hellman group 2 (1024-bit primes, more secure)

first-supported — (the default) as responder, use the first supported Diffie-Hellman group proposed by initiator
If functioning as the IKE initiator, use the optional phase1-life-seconds parameter to specify the proposed lifetime (in seconds) for the IKE SA established during IKE Phase 1 negotiations.

Allowable values are within the range 1 through 999999999 (seconds) with a default of 3600 (1 hour).

This parameter can safely be ignored if functioning as a IKE responder.
If functioning as the IKE responder, use the optional phase1-life-seconds-max parameter to specify the maximum time (in seconds) accepted for IKE SA lifetime during IKE Phase 1 negotiations.

Allowable values are within the range 1 through 999999999 (seconds) with a default of 86400 (1 day).

This parameter can safely be ignored if functioning as a IKE initiator.
If functioning as the IKE initiator, use the optional phase2-life-seconds parameter to specify the proposed lifetime (in seconds) for an IPsec SA established during IKE Phase 2 negotiations.

Allowable values are within the range 1 through 999999999 (seconds) with a default of 28800 (8 hours).

This parameter can safely be ignored if functioning as a IKE responder.
If functioning as the IKE responder, use the optional phase2-life-seconds-max parameter to specify the maximum time (in seconds) accepted for IPsec SA lifetime during IKE Phase 2 negotiations.

Allowable values are within the range 1 through 999999999 (seconds) with a default of 86400 (1 day).

This parameter can safely be ignored if functioning as a IKE initiator.
Use the optional phase2-exchange-mode parameter to specify the Diffie-Hellman group used in Phase 2 negotiations.

dh-group1 — use Diffie-Hellman group 1 (768-bit primes, less secure)

dh-group2 — use Diffie-Hellman group 2 (1024-bit primes, more secure)

no-forward-secrecy — use the same key as used during Phase 1 negotiation

Note:
Forward security indicates that compromise of a single key permits access only to data encrypted with that specific key. Failure to generate a new key for IKE Phase 2 potentially compromises additional data.

phase1-group — (the default) use the same Diffie-Hellman group as used during Phase 1 negotiation
Use the shared-password parameter to specify the PSK (pre-shared key) used during authentication with the remote IKE peer.

The PSK is a string of ACSII printable characters no longer than 255 characters (not displayed by the ACLI).

This global PSK can be over-ridden by an interface-specific PSK.
Use done, exit, and verify-config to complete configuration of IKEv1 global parameters instance.

IKEv1 Interface Configuration

To configure IKEv1 interface parameters:

From superuser mode, use the following command sequence to access ike-config configuration mode. While in this mode, you configure IKEv1 interface parameters.
```
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#
```
Use the state parameter to enable or disable this IKE interface.
Use the version parameter to specify version 1 for this IKE interface.
Use the address parameter to specify the IPv4 address of the interface.
Use the realm-id parameter to specify the realm that contains the IP address assigned to this IKEv1 interface.
Use the ike-mode parameter to specify the operational mode, either responder (the default) or initiator.
If DPD has been enabled at the global level, use the dpd-params-name parameter to assign a DPD template, an operational set of DPD parameters, to the current IKEv1 interface.

If DPD has not been enabled, this parameter can be safely ignored.
Use the optional v1-ike-life-secs parameter to set the IKE SA lifetime in seconds if you plan to use rekey on this interface.
- Default: 3600
- Range: 1 to 999999999
/use the optional v1-ipsec-life-secs parameter to set the IPsec SA lifetime in seconds if you plan to use rekey on this interface.
- Default: 28800
- Range: 1 to 999999999
v1-rekey—(Optional) Enable or disable the automatic re-keying of expired IKEv1 or IPsec SAs on this IKEv1 interface.
Use the optional shared-password parameter to assign an interface PSK.

This IKEv1-interface-specific value over-rides the global default value set at the IKE configuration level.
Use done, exit, and verify-config to complete configuration of IKEv1 interface.
Repeat Steps 1 through 7 to configure additional IKEv1 interfaces.

IKEv1 Security Association Configuration

An IKEv1 SA identifies cryptographic material available for IPsec tunnel establishment.

To configure IKEv1 SA parameters:

From superuser mode, use the following command sequence to access ike-sainfo configuration mode. While in this mode, you configure global IKEv1 SAs.
```
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-sainfo
ORACLE(ike-sainfo)#
```
Use the required name parameter to provide a unique identifier for this ike-sainfo instance.

name enables the creation of multiple ike-sainfo instances.
Use the security-protocol parameter to specify the IPsec security (authentication and encryption) protocols supported by this SA.
The following security protocols are available.

Authentication Header (AH) — the default value — as defined by RFC 4302, IP Authentication Header, which provides authentication integrity to include the mutual identification of remote peers, non-repudiation of received traffic, detection of data that has been altered in transit, and detection of data that has been replayed, that is copied and then re-injected into the data stream at a later time. Authentication services utilize the authentication algorithm specified by the auth-algo property.

Encapsulating Security Payload (ESP) as defined by RFC 4303, IP Encapsulating Security Payload, which provides both authentication and privacy services. Privacy services utilize the encryption algorithm specified by the encryption-algo property.

ESP-AUTH (also RFC 4303-based), which supports ESP’s optional authentication.

ESP-NULL (also RFC 4303-based) which proves NULL encryption as described in RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec. This option provides no privacy services, and is not recommended for production environments.

Refer to the following figures for additional details.

Figure 13-1 AH Transport Mode

Figure 13-2 AH Tunnel Mode

Figure 13-3 ESP Transport Mode

Figure 13-4 ESP Tunnel Mode
```
ORACLE(ike-sainfo)# security-protocol esp
ORACLE(ike-sainfo)#
```
Use the auth-algo parameter to specify the authentication algorithms supported by this SA.
The following authentication protocols are available

Message Digest Algorithm 5 (md5) — as defined by RFC 1321, The MD5 Message-Digest Algorithm.

Secure Hash Algorithm (sha) — as defined by RFC 3174, Secure Hash Standard.

any (the default) — supports both MD5 and SHA-1.
```
ORACLE(ike-sainfo)# auth-algo md5
ORACLE(ike-sainfo)#
```
Use the encryption-algo parameter to specify the encryption algorithms supported by this SA.
The following encryption protocols are available

Triple DES (3des) — as defined by ANSI X.9.52 1998, Triple Data Encryption Algorithm Modes of Operation.

Advanced Encryption Standard (aes) — as defined by RFC 3565, Advanced Encryption Standard.

NULL Encryption (null) — as described in RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec. This option provides no privacy services, and is not recommended for production environments.

any (the default) — supports all listed encryption protocols.
```
ORACLE(ike-sainfo)# encryption-algo aes
ORACLE(ike-sainfo)#
```
Use the ipsec-mode parameter to specify the IPSec operational mode.
Transport mode (the default) provides a secure end-to-end connection between two IP hosts. Transport mode encapsulates the IP payload.

Tunnel mode provides VPN service where entire IP packets are encapsulated within an outer IP envelope and delivered from source (an IP host) to destination (generally a secure gateway) across an untrusted internet.

Refer to the previous figures for encapsulation details.
```
ORACLE(ike-sainfo)# ipsec-mode tunnel
ORACLE(ike-sainfo)#
```
If ipsec-mode is tunnel, use the required tunnel-local-addr parameter to specify the IP address of the local IKEv1 interface that terminates the IPsec tunnel.
This parameter can safely be ignored if ipsec-mode is transport.
```
ORACLE(ike-sainfo)# tunnel-local-addr 192.169.204.14
ORACLE(ike-sainfo)#
```
If ipsec-mode is tunnel, use the tunnel-remote-addr parameter to specify the IP address of the remote IKEv1 peer that terminates the IPsec tunnel.
Provide the remote IP address, or use the default wild-card value (*) to match all IP addresses.

This parameter can safely be ignored if ipsec-mode is transport.
```
ORACLE(ike-sainfo)# tunnel-remote-addr *
ORACLE(ike-sainfo)#
```
Use done, exit, and verify-config to complete configuration of IKEv1 SA.
Repeat Steps 1 through 9 to configure additional IKEv1 SAs.

IPsec Security Policy Configuration

Use the following procedure to assign an IKEv1 SA to an existing IPsec Security Policy. Note that the network interface supported by the IPsec Security Policy must have been configured as an IKEv1 interface.

From superuser mode, use the following command sequence to access ike-config configuration mode. While in this mode, you configure global IKEv1 configuration parameters.
```
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ipsec
ORACLE(ipsec)# security-policy
ORACLE(security-policy)#
```
Use the required ike-sainfo-name parameter to assign an IKv1 SA to this IPsec Security Policy.
Use done, exit, and verify-config to complete configuration of 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® Enterprise Session Border Controller (ESBC) 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 ESBC 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 ESBC, 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 ESBC, 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.

Access the ike-config configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-config

state—Set to enable.
ike-version—Select the IKE protocol version 2.

WARNING:
Enabling version 2 in the ike-config element disables version 1 globally.
log-level—Specify the level of the IKEv2-related logs.
Log messages are listed below in descending order of severity.
- emergency
- critical
- major
- minor
- warning
- notice
- info — (default)
- trace — (test/debug, not used in production environments)
- debug — (test/debug, not used in production environments)
- detail — (test/debug, not used in production environments)
udp-port—Set to 500.
negotiation-timeout —Use the optional parameter to specify the maximum interval (in seconds) between Diffie-Hellman message exchanges.

In the absence of an explicitly configured value, the default specifies a 15 second timeout value.
v2-ike-life-secs—Specify the default lifetime (in seconds) of the IKEv2 SA.

Allowable values are within the range 1 through 999999999.
v2-ipsec-life-secs—Specify the default lifetime (in seconds) for the IPsec SA.

Allowable values are within the range 1 through 999999999.
v2-rekey —Enable or disable the re-keying of expired IKEv2 or IPsec SAs.

When v2-rekey is enabled, the ESBC initiates a new negotiation to restore an expired IKEv2 or IPsec SA. The ESBC makes a maximum of three retransmission attempts before abandoning the re-keying effort.
anti-replay —(Optional) Enable or disable anti-replay protection on IPsec SAs.
shared-password—If using a shared password, provide the PSK used while authenticating the remote IKEv2 peer.

Ensure the remote peer is configured with the same PSK.

The value of shared-password in the ike-interface configuration element takes precedence over this value.
eap-bypass-identity—(Optional) Specify whether or not to bypass the EAP identity phase.
dpd-time-interval—(Optional) Specify the maximum period of inactivity (in seconds) before the DPD protocol is initiated on an endpoint.

Values are within the range 1 through 999999999 (seconds).
overload-threshold—Set the percentage of CPU usage that triggers an overload state.

Values are within the range 1 through 100, and less than the value of overload-critical-threshold.
overload-interval—Set the interval (in seconds) between CPU load measurements while in the overload state.

Values are within the range 0 through 60 (seconds).
overload-action—Select the action to take when the Oracle Communications Session Border Controller (as a SG) CPU enters an overload state. The overload state is reached when CPU usage exceeds the percentage threshold specified by the overload-threshold.
Available values are:
- none—(the default)
- drop-new-connection—use to implement call rejection
overload-critical-threshold—Set the percentage of CPU usage that triggers a critical overload state. This value must be greater than the value of overload-threshold.

Values are within the range 1 through 100.
overload-critical-interval—Set the interval (in seconds) between CPU load measurements while in the critical overload state.

Values are within the range 0 through 60 (seconds).
sd-authentication-method—Select the method used for local authentication of the IKEv2 peer.
Two authentication methods are supported:
- shared-password — (the default) uses a pre-shared key (PSK) to authenticate the IKEv2 peer.
- certificate — uses an X.509 certificate to authenticate the IKEv2 peer.
  
  Note:
  If using a certificate for authentication, see the "Certificate Configuration Process" section in the Security chapter of the ACLI Configuration Guide.
The sd-authentication-method value can be overridden at the ike-interface level.
certificate-profile-id—If using a certificate, specify the ike-certificate-profile configuration element that contains identification and verification credentials required for PKI certificate-based IKEv2 authentication.

The ike-certificate-profile value can be over-ridden at the ike-interface level.
id-auth-type —(Optional) Specify that the PSK used while authenticating the remote IKEv2 peer is associated with the asserted identity contained within an IKEv2 Identification payload.
Note:
This attribute can be safely ignored if the PSK is defined globally or at the IKEv2 Interface level.
Available values are:
- idi—use IDi KEY_ID for authentication
- idr—use IDr KEY_ID for authentication
account-group-list—(Optional) Designate one or two existing IPsec accounting groups as available to support IPsec accounting transactions.
Type done.

RADIUS Authentication

All EAP-based authentication is performed by RADIUS servers. When such authentication is specified, the Oracle® Enterprise 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

Configure a RADIUS Server

Access the radius-servers configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# authentication
ORACLE(authentication)# radius-servers
ORACLE(radius-servers)#

state—Set the operational state of this RADIUS authentication server.
Retain the default value, enabled, to identify this RADIUS authentication server as operational. Use disabled to place this RADIUS authentication server in a non-operational mode.
authentication-methods—Specify the authentication methods supported by this RADIUS authentication server.
Valid values are:
- pap
- chap
- mschapv2
- eap
- all
address—Specify the IP address of this RADIUS authentication server.
port—Specify the remote port monitored for RADIUS authentication requests.
Valid values are:
- 1645
- 1812
realm-id—Identify the realm that provides transport services to this RADIUS authentication server.
secret—Specify the shared secret between the Oracle® Enterprise Session Border Controller and this RADIUS authentication server.
nas-id—Provide a string that uniquely identifies the ESBC to this RADIUS authentication server.
For example:
```
ORACLE(radius-servers)# nas-id nas-id-170-30-0-1
ORACLE(radius-servers)#
```
retry-limit—Specify the number of times the ESBC retransmits an unacknowledged authentication request to this RADIUS authentication server.
- Min: 1
- Max: 5
retry-time—Specify the interval (in seconds) between unacknowledged authentication requests.
- Min: 5
- Max: 10
dead-time—Specify the length (in seconds) of the quarantine period imposed an unresponsive RADIUS authentication server.
- Min: 10
- Max: 10000
maximum-sessions—Specify the maximum number of outstanding sessions for this RADIUS authentication server.
- Min: 1
- Max: 255
class—Select the RADIUS authentication server class, either primary or secondary.

The ESBC tries to initiate contact with primary RADIUS authentication servers first, and only turns to secondary RADIUS authentication servers if no primaries are available.

If more than one RADIUS authentication server is designated as primary, the ESBC uses a round-robin strategy to distribute authentication requests among available primaries.
Type done to save your configuration.
If necessary, configure additional RADIUS authentication servers.

Configure a RADIUS Authentication Servers List

Access the auth-params configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# auth-params
ORACLE(auth-params)#

name—Provide a unique name for this RADIUS Authentication Servers List.
servers—Compile a RADIUS Authentication Servers List.
Provide the IP address of a previously configured RADIUS authentication server to add that server to this list.
```
ORACLE(auth-params)# servers 172.30.0.1 172.30.0.15 168.27.3.3
ORACLE(auth-params)#
```
Type done to save your configuration.
If necessary, configure additional RADIUS Authentication Servers Lists.

Access the authentication configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# authentication
ORACLE(authentication)#

ike-radius-params-name—Assign a previously configured RADIUS Authentication Servers List to the authentication configuration element.
Type done to save your configuration.

Tearing Down IPsec Tunnels

If EAP-based authentication is used in conjunction with RADIUS-based assignment of requested local addresses, the Oracle® Enterprise 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 ESBC 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 ESBC 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 ESBC 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.

Access the ike-interface configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#

Use the select command to specify the target interface.
authorization—Enable RADIUS authorization on the selected interface.
Type done to save your configuration.
If necessary, enable RADIUS authorization on additional IKEv2 interfaces.

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® Enterprise 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 ESBC, 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 ESBC 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 ESBC. In environments where authorization is performed by a RADIUS AAA server, there are two potential sources of DNS information: local ESBC 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 ESBC 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 ESBC 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 ESBC 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® Enterprise Session Border Controller.

Access the data-flow configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# data-flow
ORACLE(data-flow)#

name—Provide a unique identifier for this  data-flow instance.
realm-id—Identify the realm that supports  data-flow upstream traffic, that is traffic toward the network core.
group-size—(Optional) Specify the maximum number of user elements grouped together by this data-flow instance.
The size of the associated local-address-pool is divided by this value to segment the address pool into smaller groups. After determining the start address for each of the smaller address groups, the ESBC uses the data-flow configuration to establish two static flows for each of the address groups — a downstream data-flow, in the access direction, and an upstream data-flow (via the realm specified by the realm-id parameter) toward a core gateway/router which provides forwarding service for the pass-thru data-flow.

Allowable values are the powers of 2 between 1 through 256.
```
ORACLE(data-flow)# group-size 32
```
upstream-rate—Specify the allocated upstream bandwidth.
- Min: 0 (allocate all available bandwidth)
- Max: 122070
downstream-rate—Specify the allocated downstream bandwidth.
- Min: 0 (allocate all available bandwidth)
- Max: 122070
Type done to save your configuration.

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.

Access the local-address-pool configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# local-address-pool
ORACLE(local-address-pool)#

name—Provide a unique identifier for this  local-address-pool instance.
dns-assignment—Identify the DNS source used to respond to incoming IKE_AUTH requests for DNS information.
- local—Use locally configured configuration data as the source of DNS information
- radius—Use a remote RADIUS AAA server as the source of DNS information.
- radius-local—Use a remote RADIUS AAA server as the preferred source of DNS information. If no DNS data is available from the RADIUS server, use locally configured DNS information.
dns-realm-id—Provide the name of the realm that supports transit to that RADIUS server.
The dns-realm-id parameter can be safely ignored if local is specified as the DNS source.
data-flow—Identify the data-flow configuration element assigned to this local-address-pool instance.
address-range—Access the address-range configuration mode.
- If building an address pool of contiguous IPv4 addresses, use network-address with subnet-mask to define a contiguous range of IPv4 addresses.
```
ORACLE(address-range)# network-address 192.168.0.0
ORACLE(address-range)# subnet-mask 255.255.255.96
```
  Note:
  The range of IPv4 addresses support only Class-B and Class-C subnet masks.
- If building an address pool of contiguous IPv6 addresses, use network-address parameter to provide both the IPv6 address and the bit length of the network prefix (an integer within the range 1 through 128). Leave the subnet-mask blank.
```
ORACLE(address-range)# network-address 1080::ac10:202/96
```
Type done to save your configuration. and exit to complete configuration of the address-range instance.
If required, add additional address ranges to this  address-range instance
Type done to complete configuration of the local-address-pool instance.

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® Enterprise 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 ESBC, 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 ESBC. When receiving an INITIAL_CONTACT message, the ESBC checks for the existence of a live tunnel with the requesting endpoint. If such a tunnel is found, the ESBC 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 ESBC, 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.

Persistent Tunnel Addressing Configuration

Use the following command sequence to enable persistent tunnel addressing.

Access the ike-config configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-config

options—Enable address persistence.

ORACLE(ike-config)# options +assume-initial-contact
ORACLE(local-address-pool)#

Type done to save your configuration.

ike-key-id Configuration

If authentication between IKEv2 peers is based on a PSK associated with an identity asserted in the IKE Identification Payload, associate received asserted identities with a specified PSK.

Access the ike-config configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-key-id
ORACLE(ike-key-id)#

name—Provide a unique identifier for this  ike-keyid instance.

Use keyid and presharedkey parameters to associate an asserted identity with a PSK.

ORACLE(ike-keyid)# keyid 172.16.20.20
ORACLE(ike-keyid)# presharedkey ************************

Type doneto save your configuration.
Repeat to configure additional ike-keyid instances.

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 ESBC 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

EAP-MSCHAPv2 is based on RFC 2759, Microsoft PPP CHAP Extensions, Version 2. This RFC describes an authentication method that uses a user-name and password model in conjunction with Microsoft encryption routines. Using EAP-MSCHAPv2, mutual authentication of the EAP peer and authenticator 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 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 ESBC 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® Enterprise 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 ESBC 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® Enterprise 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 ESBC 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 ESBC to select the appropriate attribute and ignore the other.

The ESBC 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 ESBC as a source of IPv6 addresses.Use of Framed-IPv6-Pool requires the pre-configuration of the identified address pool on the ESBC.

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 ESBC 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 ESBC 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 (ESBC) 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 ESBC 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 ESBC 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 ESBC 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.

EAP-only Authentication Configuration

Access the ike-interface configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#

Select the ike-interface object to edit.

ORACLE(ike-interface)# select
<address>:

ORACLE(ike-interface)#

eapOnlyAuthSupport — The default is enabled. Set the value to disabled to use EAP authentication together with responder authentication based on public key signatures.
Type done to save your configuration.

Debugging IKEv2 IPsec Tunnel Establishment

The Oracle® Enterprise 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® Enterprise 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.

Access the ike-interface configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#

state—Enable the IKEv2 interface.
ike-version—Set this attribute to 2.
address—Specify the IPv4 or IPv6 address of the interface.
```
ORACLE(ike-interface)# address 10.0.0.10
```
realm-id—Specify the realm that contains the IP address assigned to this IKEv2 interface.
```
ORACLE(ike-interface)# realm-id access-10
```
ike-mode—Specify whether the ESBC will act as a responder or initiator.
dpd-params-name—Enable the Dead Peer Detection Protocol on this IKEv2 interface.
The protocol is initially enabled by setting a non-zero value to the dpd-time-interval parameter during IKEv2 global configuration process. The protocol is enabled at the local level by assigning an existing dpd-params configuration element to this IKEv2 interface.

Refer to Dead Peer Detection Protocol Configuration in this chapter for information on configuring dpd-params configuration elements.
```
ORACLE(ike-interface)# dpd-params-name ikeDPD
```
v2-ike-life-seconds—(Optional) Specify the lifetime (in seconds) for the IKEv2 SAs supported by this IKEv2 interface.
The default is 86400 (24 hours).
- Min: 1
- Max: 999999999
v2-ipsec-life-seconds—(Optional) Specify the lifetime (in seconds) for the IPsec SAs supported by this IKEv2 interface.
The default is 28800 (8 hours).
- Min: 1
- Max: 999999999
v2-rekey—(Optional) Enable or disable the automatic re-keying of expired IKEv2 or IPsec SAs on this IKEv2 interface.
The default is none.
- disabled—Disable IKE/IPSEC rekey
- enabled—Enable IKE/IPSEC rekey
- none—Use the rekey value from the global ike-config element
With automatic re-keying enabled, and with the global dpd-time-interval parameter set to a non-zero value, the ESBC retransmits the re-keying request if it does not receive a response from the remote IPsec peer within the interval specified by the ike-config dpd-time-interval parameter. The ESBC makes a maximum of three retransmission attempts before abandoning the re-keying effort.
esnsupport—Enable to support Extended Sequence Number (ESN) per RFC 4304.
shared-password—If using the shared-password authentication method, set the shared password.
eap-protocol—(Optional) Set the EAP protocol.
Available values are:
- eap-md5
- eap-tls
- eap-leap
- eap-sim
- eap-srp
- eap-ttls
- eap-aka
- eap-peap
- eap-mschapv2
- eap-fast
- eap-psk
- eap-radius-passthru
sd-authentication-method—Select the interface-specific method used by IKEv2 peers to authenticate to each other.
- shared-password—Use a pre-shared-secret to authenticate the remote IKEv2 peer.
- certificate—Use an X.509 certificate to authenticate the remote IKEv2 peer.
Note:
sd-authentication-method can be safely ignored, if authentication utilizes any of the methods described in EAP-based Authentication.
```
ORACLE(ike-interface)# sd-authentication-method shared-password
```
certificate-profile-id-list—If using the certificate authentication method, identify the ike-certificate-profile configuration element that contains identification and validation credentials required for certificate-based IKEv2 authentication.
cert-status-check—(Optional) Enable certificate status checking using either Online Certificate Status Profile (OCSP) or a local copy of a Certificate Revocation List.
The default is disabled.
cert-status-profile-list—(Optional) Assign one or more cert-status-profile configuration elements to this IKEv2 interface.
Each assigned cert-status-profile provides the information needed to access either an OCSP responder or a CRL source.

Note:
Use quotation marks to assign multiple OCSP responders.
```
ORACLE(ike-interface)# cert-status-profile-list "VerisignClass3Designate Verisign-1 Thawte-1"
```
access-control-name—Specify the ike-access-control list to use on this IKE interface. The list assignment applies the IKEv2 DDOS, allowlist and blocklist protection configured within the ike-access-control object to the interface.
This parameter is meaningful only when authentication uses a RADIUS server to implement the EAP-based authentication, and can otherwise be safely ignored. Allowlists and blocklists specify IMSI prefixes or MAC addresses that are allowed through or denied access to the RADIUS authentication server.
```
ORACLE(ike-interface)# access-control-name allow_01
```
tunnel-orig-name-list—(Optional) Specify the name the tunnel-origin-params element you want to apply to this IKE interface.
Type done to save your configuration.
Configure additional IKEv2 interfaces if required.

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.

Access the ike-sainfo configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-sainfo
ORACLE(ike-sainfo)#

name—Provide a unique identifier for this ike-sainfo configuration element.
```
ORACLE(ike-sainfo)# name SA-1
```
security-protocol—Specify the IPsec security (authentication and encryption) protocols supported by this SA.
The default value is ah. Supported values are:
- ah—Authentication Header. Provides authentication integrity to include the mutual identification of remote peers, non-repudiation of received traffic, detection of data that has been altered in transit, and detection of data that has been replayed, that is copied and then re-injected into the data stream at a later time.
- esp—Encapsulating Security Payload provides both authentication and privacy services.
- esp-auth—Supports ESP’s optional authentication
- esp-null—Provides NULL encryption.
  
  WARNING:
  This option provides no privacy services and is not recommended for production environments.
auth-algo—Specify the authentication algorithms supported by this SA.
Available protocols are:
- any
- md5
- sha1
- xcbc
- sha2-256
- sha2-384
- sha2-512
encryption-algo—Specify the encryption algorithms supported by this SA.
The default is aes. Available protocols are:
- any—Choose any
- 3des—Triple DES
- aes—AES with CBC mode
- aes-ctr—AES with counter mode
- null—NULL encryption
ipsec-mode—Specify the IPsec operational mode.
- tunnel—Provides a secure end-to-end connection between two IP hosts.
- transport—Provides VPN service where the entire IP packets are encapsulated within an outer IP envelope and delivered from source (an IP host) to destination (generally a secure gateway) across an untrusted internet.
tunnel-local-addr—If using tunnel mode, specify the IP address of the local IKEv2 interface that terminates the IPsec tunnel.
```
ORACLE(ike-sainfo)# tunnel-local-addr 172.30.89.10
```
tunnel-remote-addr—If using tunnel mode, specify the IP address of the remote IKEv2 peer that terminates the IPsec tunnel.
Provide the remote IP address or use the default wild-card value (*) to match all IP addresses.
```
ORACLE(ike-sainfo)# tunnel-remote-addr *
```
Type done to save your configuration.
If necessary, configure additional IPsec SAs.

Security Policy Configuration

Use the following procedure to define an IPsec Security Policy.

Access the security-policy configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ipsec
ORACLE(ipsec)# security-policy
ORACLE(security-policy)#

name—Identify this IPsec Security Policy.
```
ORACLE(security-policy)# name requireIPsec
```
network-interface—Provide the network interface name of the IKEv2 interface to which this security policy is applied.
```
ORACLE(security-policy)# network-interface M00:0
```
priority—(Optional) Assign a priority to this IPsec Security Policy.
- Highest priority: 0
- Lowest priority: 123
action—Specify the processing of IPsec and non-IPsec traffic streams.
- allow—Process non-IPsec traffic
- ipsec—Allow only IPsec traffic
- srtp—Allow only SRTP traffic
- srtcp—Allow only SRTCP traffic
direction—Identity the traffic streams subject to the processing specified by the action parameter.
Available values are:
- in
- out
- both
local-ip-addr-match—(Optional) Specify the local IP address of the network interface.
Provide the local IP address or retain the default value, 0.0.0.0, which matches all local IP addresses.
```
ORACLE(security-policy)# local-ip-addr-match 172.30.89.10
```
remote-ip-addr-match—(Optional) Specify the IP address of the remote IKEv2 peer.
Provide the remote IP address or retain the default value, 0.0.0.0, which matches all remote IP addresses.
```
ORACLE(security-policy)# remote-ip-addr-match 0.0.0.0
```
local-port-match—(Optional) Specify the local ports to which this IPsec Security applies.
Use 0 to specify all local ports.
- Min: 1
- Max: 65535
local-port-match-max—(Optional) Specify the maximum value for the local port to which this IPsec Security applies.
- Default: 65535
- Min: 0
- Max: 65535
remote-port-match—(Optional) Specify the remote ports to which IPsec Security Policy applies.
Use 0 to specify all remote ports.
- Min: 1
- Max: 65535
remote-port-match-max—(Optional) Specify the maximum value for the remote port to which this IPsec Security applies.
- Default: 65535
- Min: 0
- Max: 65535
ike-sainfo-name—Assign an IPsec data SA to this Security Policy.
Type done to save your configuration.

Note:
Oracle recommends you configure the local-port-match-max or remote-port-match-max value under security-policy to allow processing of IPsec or non-IPsec traffic streams, based on the action configured.

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® Enterprise 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 ESBC is handling packet intensive services such as video streaming or long duration calls. In accordance with RFCs 4303 and 7296, the ESBC 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

Issuing this command shows, along with other existing IPSec PPM-related statistics, the total number of times SN overflow occurred. The four pertinent parameters are:

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.

IPSec SA Rekey on Sequence Number Overflow Configuration

Access the ipsec-global-config configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ipsec
ORACLE(ipsec)# ipsec-global-config
ORACLE(ipsec-global-config)#

Select the ipsec-global-config object to edit.

ORACLE(ipsec-global-config)# select
ORACLE( ipsec-global-config)#

rekey-on-sn-overflow — Identifies whether to enable IPSec rekey on sequence number (SN) or extended sequence number (ESN) overflow. Rekey initiation is independent of the value of the parameter v2-rekey in the ike-interface configuration element. Allowable values are enabled and disabled. The default is enabled.
sn-rekey-threshold — Identifies the threshold for triggering an IPSec security association (SA) rekey on SN or ESN overflow as a percentage of the SN (32-bit) or ESN (64-bit) number space. The allowable range is 80 to 100 and the default is 95.
Type done to save your configuration.

Pre-Populated ARP Table

In certain topologies remote IPsec endpoints can require access to core network hosts reachable through a Oracle® Enterprise Session Border Controller core interface. In these instances, the ESBC 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 ESBC 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.

Pre-Populate An Interface-Specific ARP Table

Access the network-interface configuration element.

ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-interface
ORACLE(network-interface)

Select the network-interface object to edit.

ORACLE(network-interface)# select
<name>:<sub-port-id>:
1: wancom0:0 ip=10.0.0.2 gw=10.0.4.1

selection: 1
ORACLE(network-interface)#

add-neighbor-ip—Add the initial IP address to the  core-interface-specific ARP table.
```
ORACLE(network-interface)# add-neighbor-ip 10.0.0.101
```
If necessary, add an additional IP address to the core-interface-specific ARP table.

You can add a maximum of ten IP addresses to a single network interface.

Use the show command to examine the pre-populated ARP table, referred to as the neighbor list.

ORACLE(network-interface)# show
network-interface
        ...
        neighbor-list                  10.0.0.101
                                       10.0.0.102
                                       10.0.0.103
                                       10.0.0.104
                                       10.0.0.105
                                       10.0.0.106
                                       10.0.0.107
                                       10.0.0.108
                                       10.0.0.109
                                       10.0.0.110
        ...

Type done to save your configuration.

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.

Access the dpd-params configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# dpd-params
ORACLE(dpd-params)#

name—Provide a unique identifier for this  dpd-params instance.
```
ORACLE(dpd-params)# name ikeDPD
```
max-loop—Specify the maximum number DPD peers whose liveliness is examined every dpd-interval period.
Periodic liveliness is tested by the Oracle® Enterprise Session Border Controller issuing an R-U-THERE message to each peer in the current group. If the peer acknowledges receipt of the message, it is confirmed as alive. If the peer fails to respond, its status is determined by the max-retrans and max-attempts parameter values.
- Min: 1
- Max: 999999999
max-retrans—Specify the maximum number of times that the ESBC, acting as a DPD initiator, retransmits an unacknowledged R-U-THERE message while performing periodic liveliness tests.
The default is 3.
- Min: 1
- Max: 4
max-attempts—Specify the number of failed liveliness tests required to declare a peer as dead and take down the IKE tunnel.
The default is 1.
- Min: 1
- Max: 4
max-endpoints—Specify the maximum number of simultaneous DPD protocol negotiations supported when the CPU is not under load, as specified by max-cpu-limit.
The default is 25.
- Min: 1
- Max: 15000
If CPU workload surpasses the threshold set by max-cpu-limit, this value is over-ridden by load-max-endpoints.
max-cpu-limit—Specify a threshold value (expressed as a percentage of CPU capacity) at which DPD protocol operations are minimized to conserve CPU resources.
The default is 60.
- Min: 0
- Max: 100
load-max-loop—Specify the maximum number of endpoints examined every dpd-time-interval when the CPU is under load, as specified by max-cpu-limit.
The default is 40.
- Min: 1
- Max: 999999999
Ensure that the configured value is less than the value assigned to max-loop.
load-max-endpoints—Specify the maximum number of simultaneous DPD Protocol negotiations supported when the CPU is under load, as specified by max-cpu-limit.
The default is 5.
- Min: 1
- Max: 15000
Ensure that the configured value is less than the value assigned to max-endpoints.
Type done to save your configuration.
If necessary, configure additional dpd-params configuration elements.

Access the ike-interface configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#

dpd-params-name—Enable Dead Peer Detection on this IKEv2 interface.
```
ORACLE(ike-interface)# dpd-params-name ikeDPD
```
Type done to save your configuration.

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® Enterprise 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.

Access the cert-status-profile configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# cert-status-profile
ORACLE(cert-status-profile)#

name—Provide a unique name for this profile.
type—Select the certificate revocation check method.
Available values are:
- OCSP
- CRL
Specify either the IP address or the hostname of the CRL source.
- ip-address—Specify the IP address of the CRL source.
- host-name—Specify the hostname of the CRL source
Note:
If values are provided for both attributes, the ESBC uses the IP address and ignores the host-name value.
crl-list—Specify the source filepath(s) to one or more requested CRLs.
For example:
```
ORACLE(cert-status-profile)# crl-list /crl/v2/tc_class_3_ca_II.crl
```
realm-id—Specifies the realm used to request and receive CRLs.

In the absence of an explicitly configured value, the ESBC provides a default value of wancom0, specifying CRL-related transmissions across the wancom0 management interface.

Note:
If the CRL source is identified by its FQDN, the realm identified by realm-id must be DNS-enabled.
responder-cert—Identify the certificate used to validate the received CRL (the public key of the CRL source).

Provide the name of the certificate configuration element that contains the certificate used to validate the signed CRL.
retry-count—Specify the maximum number of times to retry an CRL source in the event of connection failure.
The default is 1.
- Min: 0
- Max: 10
dead-time—Specify the quarantine period imposed on an unavailable CRL source.
The default is 0.
- Min: 0
- Max: 3600
crl-update-interval—Specify the interim in seconds between CRL updates.
The default is 86400.
- Min: 600
- Max: 2600000
CRLs are stored in the /code/crls directory. Outdated, invalid CRLs are over-written with the each newly-obtained current CRL.
Type done to save your configuration.
If necessary, configure additional cert-status-profile configuration elements.

SNMP Traps

An SNMP trap is thrown, and a major alarm generated, if the Oracle® Enterprise 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 ESBC 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.

Configure OCSP Certificate Verification

Access the cert-status-profile configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# cert-status-profile
ORACLE(cert-status-profile)#

name—Provide a unique name for this profile.
Specify either the IP address or the hostname of the CRL source.
- ip-address—Specify the IP address of the CRL source.
- host-name—Specify the hostname of the CRL source
Note:
If values are provided for both attributes, the ESBC uses the IP address and ignores the host-name value.
port—Identifies the port monitored by the HTTP server for incoming OCSP requests.

The port attribute can be safely ignored if the ESBC is specified as a FQDN by the host-name attribute, but is required if the ESBC is identified by the ip-address attribute.
type—Select the certificate revocation check method.
Available values are:
- OCSP
- CRL
trans-protocol—Retain the default value (http) for trans-protocol attribute, which identifies the transport method used to access the ESBC.
requester-cert—Specify the certificate used to sign requests.
Ignore this attribute if requests are not signed. If a signed request is required by the OCSP responder, provide the name of the certificate configuration element that contains the certificate used to sign OCSP requests.
responder-cert—Identifies the certificate used to validate signed OCSP response (a public key of the OCSP responder).

Note:
RFC 2560 requires that all OCSP responders digitally sign OCSP responses, and that OCSP requesters validate incoming signatures.
trusted-cas—A list of certificate configuration objects that identifies the approved DoD-approved CAs that sign ESBC certificates.

In DISA/DoD environments that support the delegated trust model, you must provide a list of CAs used to validate the received certificate.

If a certificate or a certificate chain is appended to the OCSP response, the OCSP client verifies that the first certificate signed the response, and that the CA is trusted by the ESBC (that is, the CA certificate is contained in the trusted-cas list. The client then walks through each additional certificate (if any exist) ensuring that each certificate is also trusted. If all certificates are trusted, the OCSP response is accepted; otherwise, it is rejected.
realm-id—Specify the realm used to transmit OCSP requests and receive OCSP responses.

In the absence of an explicitly configured value, the ESBC provides a default value of wancom0, specifying OCSP protocol transmissions across the wancom0 management interface.
retry-count—Specify the maximum number of times to retry an CRL source in the event of connection failure.
The default is 1.
- Min: 0
- Max: 10
dead-time—Specify the quarantine period imposed on an unavailable CRL source.
The default is 0.
- Min: 0
- Max: 3600
Type done to save your configuration.
If necessary, configure additional cert-status-profile configuration elements.

SNMP Traps

An SNMP trap is thrown if a configured OSCP responder becomes unreachable.

A second SNMP trap is thrown when connectivity is re-established with a previously unreachable OCSP responder.

Enable Certificate Verification on an IKEv2 Interface

Access the ike-interface configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#

Select the ike-interface object to edit.

ORACLE(ike-interface)# select
<address>:

ORACLE(ike-interface)#

cert-status-check—Enable certificate status checking on this IKEv2 interface.
cert-status-profile-list—Assign a CRL source or sources to the IKEv2 interface
Note:
Use quotation marks to assign multiple CRL sources.
```
ORACLE(ike-interface)# cert-status-profile-list "CRL1-VS CRL2-VS CRL3-VS"
ORACLE(ike-interface)#
```
Type done to save your configuration.

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® Enterprise 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 ESBC 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 ESBC. A group of policing parameters, and associated counters, provide protection against DDoS attacks by monitoring IKEv2 signaling from individual endpoints. The ESBC 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 ESBC 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.

From superuser mode, use the following command sequence to access  ike-access-control configuration mode.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-access-control
ORACLE(ike-access-control)#

Use the required name parameter to assign a unique name to this IKEv2 Access Control Template instance.
You will use this name as an identifier when assigning the template to a specific IKEv2 interface.
```
ORACLE(ike-access-control)# name ikev2-ddos-1
ORACLE(ike-access-control)#
```
Use the state parameter to enable or disable this template instance.
Supported values are enabled (the default) and disabled.
```
ORACLE(ike-access-control)# state enabled
ORACLE(ike-access-control)#
```
Use the tolerance-window parameter to specify the interval (in seconds) between checks of endpoint-specific traffic counters.
At the specified interval, the Oracle® Enterprise Session Border Controller checks the value of each of the counters associated with one of the policing parameters. If the counter value is less than the threshold value set by the policing parameter, the counter is cleared, and the endpoint remains in the allowed state. If the counter value is equal to or greater than the threshold value, the counter is cleared, and the endpoint is placed in the deny state.

tolerance-window and deny-period must both be set to non-zero values to enable IKEv2 DDOS protection.

Supported values are integers within the range 0, the default, through 999999999 (packets). The default value, 0, specifies that no IKEv2 DDOS protection is enabled.
```
ORACLE(ike-access-control)# tolerance-window 100
ORACLE(ike-access-control)#
```
Use the deny-period parameter to specify the quarantine period imposed on an endpoint that transitions to the deny state. During the quarantine period, the endpoint is denied all access to the IKEv2 interface.
deny-period and tolerance-window must both be set to non-zero values to enable IKEv2 DDOS protection.

Supported values are integers within the range 0 through 999999999, with a default value of 30 (seconds).
```
ORACLE(ike-access-control)# deny-period 50
ORACLE(ike-access-control)#
```
Use the pre-ipsec-invalid-threshold parameter to enable protection against a DDOS attack that sends malformed, or otherwise invalid, packets during the IKEv2 SA negotiation process.
pre-ipsec-invalid-threshold specifies the maximum number of malformed IKEv2 SA packets tolerated from a specific endpoint within the interval set by the tolerance-window parameter. These attacks can attempt to consume system resources in a futile effort to complete negotiation of IKEv2 SAs.

If this threshold value is reached, the endpoint is quarantined for an interval defined by the deny-period parameter.

Supported values are integers within the range 0, the default, through 999999999 (packets). The default value, 0, specifies that protection against malformed or invalid IKEv2 SA negotiation packets is not enabled.
```
ORACLE(ike-access-control)# pre-ipsec-invalid-threshold 10
ORACLE(ike-access-control)#
```
Use the pre-ipsec-maximum-threshold parameter to enable protection against an IKEv2 DDOS attack that sends excessive packets during the IKEv2 SA negotiation process.
pre-ipsec-maximum-threshold specifies the maximum number of valid IKEv2 SA packets tolerated from a specific endpoint within the interval set by the tolerance-window parameter. These attacks can attempt to prolong the IKEv2 negotiation by persistently renegotiating the IKEv2 SA.

If this threshold value is reached, the endpoint is quarantined for an interval defined by the deny-period parameter.

Supported values are integers within the range 0, the default, through 999999999 (packets). The default value, 0, specifies that protection against valid, but excessive, IKEv2 SA negotiation packets is not enabled.
```
ORACLE(ike-access-control)# pre-ipsec-maximum-threshold 100
ORACLE(ike-access-control)#
```
Use the invalid-cookie-threshold parameter to enable protection against an IKEv2 DDOS attack that prolongs the IKEv2 SA negotiation process by having the endpoint deliberately fail to follow required protocol behavior, as defined in Section 2.6 of RFC 4306, Internet Key Exchange (IKEv2) Protocol.
During the IKEv2 negotiation process, the ESBC can issue an IKE_SA_INIT response that contains a cookie notification payload. The payload mandates that the endpoint retry IKEv2 SA negotiation with the cookie value as the first payload in its response to the IKE_SA_INIT.

invalid-cookie-threshold specifies the maximum number of packets containing an erroneous cookie value tolerated from a specific endpoint within the interval set by the tolerance-window parameter.

If this threshold value is reached, the endpoint is quarantined for an interval defined by the deny-period parameter.

Supported values are integers within the range 0, the default, through 999999999 (packets). The default value, 0, specifies that protection against erroneous cookie responses is not enabled.
```
ORACLE(ike-access-control)# invalid-cookie-threshold 10
ORACLE(ike-access-control)#
```
Use the after-ipsec-invalid-threshold parameter to enable protection against an IKEv2 DDOS attack that sends malformed IKEv2 SA packets after the establishment of an IPsec tunnel.
after-ipsec-invalid-threshold specifies the maximum number of malformed, or otherwise invalid, IKEv2 SA packets tolerated from a specific endpoint within the interval set by the tolerance-window parameter. These attacks can attempt to consume system resources in a futile effort to renegotiate the IKEv2 SA.

If this threshold value is reached, the endpoint is quarantined for an interval defined by the deny-period parameter.

Supported values are integers within the range 0, the default, through 999999999 (packets). The default value, 0, specifies that protection against malformed or invalid IKEv2 SA renegotiation packets is not enabled.
```
ORACLE(ike-access-control)# post-ipsec-invalid-threshold 10
ORACLE(ike-access-control)#
```
Use the after-ipsec-maximum-threshold parameter to enable protection against an IKEv2 DDOS attack that sends valid, but excessive, IKEv2 SA packets after the establishment of an IPsec tunnel.
after-ipsec-maximum-threshold specifies the maximum number of valid IKEv2 SA packets tolerated from a specific endpoint within the interval set by the tolerance-window parameter. These attacks can attempt to consume system resources by persistently renegotiating the IKEv2 SA.

If this threshold value is reached, the endpoint is quarantined for an interval defined by the deny-period parameter.

Supported values are integers within the range 0, the default, through 999999999 (packets). The default value, 0, specifies that protection against valid, but excessive, IKEv2 SA negotiation packets is not enabled.
```
ORACLE(ike-access-control)# post-ipsec-maximum-threshold 1000
ORACLE(ike-access-control)#
```
Use the auth-failure-threshold parameter in conjunction with auth-failure-threshold-report to enable protection against an IKEv2 DDOS attack that attempts to consume system resources by overwhelming the authentication function.
auth-failure-threshold specifies the maximum number of failed authentication attempts tolerated from a specific endpoint within the interval set by the tolerance-window parameter. These attacks attempt to consume system resources by persistently presenting invalid credentials during the endpoint authentication process.

If this threshold value is reached, the endpoint is quarantined for an interval defined by the deny-period parameter.

Supported values are integers within the range 0, the default, through 999999999 (authentication attempts). The default value, 0, specifies that protection against invalid authentications is not enabled.
```
ORACLE(ike-access-control)# auth-failure-threshold 10
ORACLE(ike-access-control)#
```
Use the auth-failure-threshold-report parameter in conjunction with auth-failure-threshold to enable protection against an IKEv2 DDOS attack that attempts to consume system resources by overwhelming the authentication function.
auth-failure-threshold-report specifies how failed authentications are reported. Supported values are:
- no-reporting—(the default), authentication failures are not reported
- snmp-trap-only—authentication failures are reported by generating an SNMP trap (refer to SNMP Trap for information of trap structure)
- syslog-only—authentication failures are reported by sending a syslog message
- snmp-trap-and-syslog—authentication failures are reported with both an SNMP trap and a syslog message
```
ORACLE(ike-access-control)# auth-failure-threshold-report snmp-trap-only
ORACLE(ike-access-control)#
```
Use done, exit, and verify-config to complete configuration of the IKEv2 Access Control Template.
Repeat Steps 1 through 13 to complete additional IKEv2 Access Control templates if required.

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.

From superuser mode, use the following command sequence to access ike-interface configuration mode

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#

Use the select command to specify the interface to which the IKEv2 Access Control Template will be assigned.

ORACLE(ike-interface)# select
<address>:
172.30.1.150
172.30.1.151
172.30.55.127
selection: 1
ORACLE(ike-interface)#

Use the access-control-name parameter to assign an IKEv2 Access Control Template to the interface.
```
ORACLE(ike-interface)# access-control-name ikev2-ddos-1
ORACLE(ike-interface)#
```
Use done, exit, and verify-config to complete IKEv2 Access Control Template assignment.

SNMP Trap

Violation of the authenticate failure threshold can generate an SNMP trap that includes the endpoint’s ID or MSISDN (Mobile Station International Subscriber Directory Number), its IP address, and port number.

High Availability

IKE counters that track suspected IKEv2 DDOS attacks are not synchronized with the standby Oracle® Enterprise Session Border Controller. Endpoint deny status, however, is synchronized with the standby.

Configuring White and Black Lists with Access Control

The ESBC supports IKEv2 access-control white lists that permit authentication only for a provisioned list of IMSI prefixes or MAC addresses. The ESBC 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® Enterprise 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® Enterprise Session Border Controller passes the received IMSI identity to the RADIUS server. In order to minimize server processing, the ESBC 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 ESBC. 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.

Sample identifiers are as follows:

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.

Access the ike-access-control configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-access-control
ORACLE(ike-access-control)#

name—Provide a unique identifier.

ORACLE(ike-access-control)# name white_01

state—Enable access control.
identifier—Provide one or more MCC or MCC/MNC match patterns for IMSI-based whitelisting.
This identifier, a literal string, matches the Russian Federation.
```
ORACLE(ike-access-control)# identifier 250
```
This identifier, which uses the wildcard symbol (^) signifying any single digit within the range 0 through 9, matches the continental United States.
```
ORACLE(ike-access-control)# identifier 31^
```
This identifier, a double-quote delimited list of prefixes separated by spaces, matches T-Mobile United States networks.
```
ORACLE(ike-access-control)# identifier "26201 26206"
```
This identifier, a double-quote delimited list of prefixes separated by spaces, matches Verizon Wireless United States networks.
```
ORACLE(ike-access-control)# identifier "310004 310012"
```
For MAC-based whitelisting, the following double-quote delimited list identifies three specific MAC addresses.
```
ORACLE(ike-access-control)# identifier "0123456789AB 6789912345BF DA2345918290"
```
Note:
Do not configure an empty white list. Assigning an empty white list to an IKEv2 interface results in authentication failure for all presented identities.
Type done to save your configuration.
If necessary, configure additional ike-access-control configuration elements.

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 ESBC and are not applicable for clients doing password-based or certificate-based authentication.

Access the ike-access-control configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-access-control
ORACLE(ike-access-control)#

name—Provide a unique identifier.

ORACLE(ike-access-control)# name black_01

state—Enable access control.
blacklisted-dentifiers—Provide one or more MAC-based match patterns for MAC-address-based black lists.
The following double-quote delimited list identifies three specific MAC addresses whose authentication is summarily rejected.
```
ORACLE(ike-access-control)# blacklisted-dentifiers "0123456789AB 6789912345BF DA2345918290"
```
This identifier, which uses the wildcard symbol (^) signifying any single hexadecimal digit, specifies two ranges of contiguous MAC addresses.
```
ORACLE(ike-access-control)# blacklisted-dentifiers "0123456789A^, ^123456789AB"
```
For IMSI-based black lists, this example uses a double-quote delimited list of prefixes separated by spaces, to match Verizon Wireless United States networks.
```
ORACLE(ike-access-control)# blacklisted-dentifiers "310004 310012"
```
Note:
Do not configure an empty black list. Assigning an empty black list to an IKEv2 interface results in authentication eligibility for all presented identities.
Tyoe done to save your configuration.
If necessary, configure additional ike-access-control configuration elements.

Assign a White List or Black List to an IKEv2 Interface

Access the ike-interface configuration element.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#

Select the ike-interface object to edit.

ORACLE(ike-interface)# select
<address>:

ORACLE(ike-interface)#

access-control-name—Identify the white list or black list assigned to the current interface.
```
ORACLE(ike-interface)# access-control-name white_01
```
Type done to save your configuration.

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.

If neither a white list nor a black list are assigned to an IKEv2 interface, all EAP authentication requests are forwarded to a RADIUS authentication server for final determination.
If only a white list is assigned to an IKEv2 interface, the incoming EAP identity is to be checked against that white list. If the EAP identity is contained in the white list, the authentication request is forwarded to a RADIUS authentication server for final determination. If the EAP identity is absent, authentication is denied.
If only a black list is assigned to an IKEv2 interface, the incoming EAP identity is checked against that black list. If the EAP identity is contained in the black list, authentication is denied. If the EAP identity is absent, the authentication request is forwarded to a RADIUS authentication server for final determination..
If both a white list and a black list are assigned to an IKEv2 interface, the ESBC checks both the white and the black list for incoming EAP identity.

If the EAP identity is contained in the white list, and absent from the black list, the authentication request is forwarded to a RADIUS authentication server for final determination.

If the EAP identity is contained in the black list and absent from the white list, authentication is rejected.

If the EAP identity is present in both the lists, the black list takes priority. Consequently, authentication is rejected. This situation will have been previously reported by the verify-config ACLI command.

If the EAP identity is absent from both the lists, the white list takes priority. Consequently, since the EAP identity is not contained in the white list the authentication is denied.

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 ESBC 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.

From superuser mode, use the following command sequence to access security-policy configuration mode. While in this mode, you configure new security policies or modify existing policies.
```
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ipsec
ORACLE(ipsec)# security-policy
ORACLE(security-policy)#
```

Use the required name parameter to identify this policy.

ORACLE(security-policy)# name deny_icmp-type0_code0
ORACLE(security-policy)#

Use the required network-interface parameter to provide the network interface name of the IKEv2 interface to which this security policy is applied.
```
ORACLE(security-policy)# network-interface M00:433
ORACLE(security-policy)#
```
Use the optional local-ip-addr-match parameter to specify the local IP address of the network interface.
Provide the local IP address or retain the default value, 0.0.0.0, which matches all local IP addresses.
```
ORACLE(security-policy)# local-ip-addr-match 192.168.89.10
ORACLE(security-policy)#
```

Use the optional local-ip-mask parameter to specify the local address mask.

ORACLE(security-policy)# local-ip-mask 255.255.0.0
ORACLE(security-policy)#

Use the optional remote-ip-addr-match parameter to specify the local IP address of the network interface.
Provide the remote IP address or retain the default value, 0.0.0.0, which matches all remote IP addresses.
```
ORACLE(security-policy)# remote-ip-addr-match 15.0.0.0
ORACLE(security-policy)#
```

Use the optional remote-ip-mask parameter to specify the remote address mask.

ORACLE(security-policy)# local-ip-mask 255.0.0.0
ORACLE(security-policy)#

Use the optional local-port-match parameter in conjunction with the local-port-match-max parameter to specify a contiguous range of local ports to which this security policy applies.

To specify a single local port:

ORACLE(security-policy)# local-port-match 64000
ORACLE(security-policy)# local-port-match-max 64000
ORACLE(security-policy)#

To specify a local port range:

ORACLE(security-policy)# local-port-match 64000
ORACLE(security-policy)# local-port-match-max 64500
ORACLE(security-policy)#

To specify all local ports:

ORACLE(security-policy)# local-port-match 0
ORACLE(security-policy)# local-port-match-max 65535
ORACLE(security-policy)#

Use the optional remote-port-match parameter in conjunction with the remote-port-match-max parameter to specify a contiguous range of remote ports to which this security policy applies.

To specify a single remote port:

ORACLE(security-policy)# remote-port-match 32000
ORACLE(security-policy)# remote-port-match-max 32000
ORACLE(security-policy)#

To specify a local port range:

ORACLE(security-policy)# remote-port-match 64000
ORACLE(security-policy)# remote-port-match-max 64500
ORACLE(security-policy)#

To specify all local ports:

ORACLE(security-policy)# remote-port-match 0
ORACLE(security-policy)# remote-port-match-max 65535
ORACLE(security-policy)#

Use the optional priority parameter to assign a priority to this security policy.
Supported values are integers within the range 0 (the highest priority) through 254 (the lowest priority).

You can assign more than one security policy to a specific interface. With multiple security policy assignments, each policy is applied in order of its priority (highest to lowest).
```
ORACLE(security-policy)# priority 0
ORACLE(security-policy)#
```
Use the optional trans-protocol-match parameter to identify the filtered protocol, in this example, ICMP.
```
ORACLE(security-policy)# trans-protocol-match icmp
ORACLE(security-policy)#
```
Use the optional trans-sub-protocol-match parameter to identify a specific ICMP message type.
The ICMP 8-bit Type field specifies the message type. Contents of the Type field are administered by the Internet Assigned Numbers Authority (IANA). Current Type numbers can be viewed at http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml#icmp-parameters-types.

The following command sequence designates the ICMP Echo Reply message.
```
ORACLE(security-policy)# trans-sub-protocol-match 0
ORACLE(security-policy)#
```
Use the optional trans-sub-protocol-code-match parameter to identify a specific ICMP code.
Many ICMP message types have associated numeric codes which provide additional information pertinent to that message types. ICMP code values are administered by the Internet Assigned Numbers Authority (IANA). Up to date codes can be viewed at http://www.iana.org/assignments/icmp-parameters/icmp-parameters.xml#icmp-parameters-codes.

In the absence of a specifically identified code, all codes are filtered.

The following command sequence designates the Net Unreachable code.
```
ORACLE(security-policy)# trans-sub-protocol-code-match 0
ORACLE(security-policy)#
```
Use the optional action parameter to specify how incoming ICMP messages that match filtering criteria are processed.
Use discard to drop all ICMP messages that match filtering criteria.

Use allow to pass-thru all ICMP messages that match filtering criteria.
```
ORACLE(security-policy)# action discard
ORACLE(security-policy)#
```
Use the optional direction parameter to identity the traffic streams subject to the processing specified by the action parameter.
Use both to apply the specified processing to both inbound and outbound traffic.
```
ORACLE(security-policy)# direction both
ORACLE(security-policy)#
```
Ignore the ike-sainfo-name parameter.
Use done, exit, and verify-config to complete configuration of the security policy.
Repeat Steps 1 through 17 to configure additional security policies.

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.

From superuser mode, use the following command sequence to access security-policy configuration mode. While in this mode, you configure new security policies or modify existing policies.
```
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ipsec
ORACLE(ipsec)# security-policy
ORACLE(security-policy)#
```

\Use the required name parameter to identify this policy.

ORACLE(security-policy)# name allow_sctp-ppid_46
ORACLE(security-policy)#

Use the required network-interface parameter to provide the network interface name of the IKEv2 interface to which this security policy is applied.
```
ORACLE(security-policy)# network-interface M00:433
ORACLE(security-policy)#
```
Use the optional local-ip-addr-match parameter to specify the local IP address of the network interface.
Provide the local IP address or retain the default value, 0.0.0.0, which matches all local IP addresses.
```
ORACLE(security-policy)# local-ip-addr-match 192.168.89.10
ORACLE(security-policy)#
```

Use the optional local-ip-mask parameter to specify the local address mask.

ORACLE(security-policy)# local-ip-mask 255.255.0.0
ORACLE(security-policy)#

Use the optional remote-ip-addr-match parameter to specify the remote IP address of the network interface.
Provide the remote IP address or retain the default value, 0.0.0.0, which matches all local IP addresses.
```
ORACLE(security-policy)# remote-ip-addr-match 192.168.89.10
ORACLE(security-policy)#
```

Use the optional remote-ip-mask parameter to specify the remote address mask.

ORACLE(security-policy)# remote-ip-mask 255.255.0.0
ORACLE(security-policy)#

Use the optional local-port-match parameter in conjunction with the local-port-match-max parameter to specify a contiguous range of local ports to which this security policy applies.

To specify a single local port:

ORACLE(security-policy)# local-port-match 64000
ORACLE(security-policy)# local-port-match-max 64000
ORACLE(security-policy)#

To specify a local port range:

ORACLE(security-policy)# local-port-match 64000
ORACLE(security-policy)# local-port-match-max 64500
ORACLE(security-policy)#

To specify all local ports:

ORACLE(security-policy)# local-port-match 0
ORACLE(security-policy)# local-port-match-max 65535
ORACLE(security-policy)#

Use the optional remote-port-match parameter in conjunction with the remote-port-match-max parameter to specify a contiguous range of remote ports to which this security policy applies.

To specify a single remote port:

ORACLE(security-policy)# remote-port-match 32000
ORACLE(security-policy)# remote-port-match-max 32000
ORACLE(security-policy)#

To specify a local port range:

ORACLE(security-policy)# remote-port-match 64000
ORACLE(security-policy)# remote-port-match-max 64500
ORACLE(security-policy)#

To specify all local ports:

ORACLE(security-policy)# remote-port-match 0
ORACLE(security-policy)# remote-port-match-max 65535
ORACLE(security-policy)#

Use the optional priority parameter to assign a priority to this security policy.
Supported values are integers within the range 0 (the highest priority) through 254 (the lowest priority).

You can assign more than one security policy to a specific interface. With multiple security policy assignments, each policy is applied in order of its priority (highest to lowest).
```
ORACLE(security-policy)# priority 0
ORACLE(security-policy)#
```
Use the optional trans-protocol-match parameter to identify the filtered protocol, in this example, SCTP.
```
ORACLE(security-policy)# trans-protocol-match sctp
ORACLE(security-policy)#
```
Use the optional trans-sub-protocol-match parameter to identify a specific SCTP Protocol Payload Identifier.
SCTP DATA chunks contain a 32-bit Payload Protocol Identifier field specifying the protocol that originated the data contained in the SCTP chunk. SCTP Payload Protocol Identifiers are administered by the IANA. Current identifiers can be found at http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xml#sctp-parameters-25.

The following command sequence designates DIAMETER data.
```
ORACLE(security-policy)# trans-sub-protocol-match 46
ORACLE(security-policy)#
```
Ignore the optional trans-sub-protocol-code-match parameter, which is not currently used for SCTP filter configuration.
Use the optional action parameter to specify how incoming SCTP messages that match filtering criteria are processed.
Use discard to drop all SCTP messages that match filtering criteria.

Use allow to pass-thru all SCTP messages that match filtering criteria.
```
ORACLE(security-policy)# action allow
ORACLE(security-policy)#
```
Use the optional direction parameter to identity the traffic streams subject to the processing specified by the action parameter.
Use both to apply the specified processing to both inbound and outbound traffic.
```
ORACLE(security-policy)# direction both
ORACLE(security-policy)#
```
Ignore the ike-sainfo-name parameter.
Use done, exit, and verify-config to complete configuration of the security policy.
Repeat Steps 1 through 17 to configure additional security policies.

Source Routing Packets

The ESBC 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.

From superuser mode, use the following command sequence to access ipsec-global-config configuration mode.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ipsec
ORACLE(ipsec)# ipsec-global-config
ORACLE(ipsec-global-config)#

Use the options command in conjunction with the source-routing-drop argument to unconditionally discard all source routing packets — identified by the presence of either an SSRR or LSRR option in the IP header Options header.
```
ORACLE(ipsec-global-config)# options +source-routing-drop
ORACLE(ipsec-global-config)#
```
Use the done and exit to complete configuration.

Fragmented Packets

The ESBC 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.

From superuser mode, use the following command sequence to access ipsec-global-config configuration mode.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ipsec
ORACLE(ipsec)# ipsec-global-config
ORACLE(ipsec-global-config)#

Use the options command in conjunction with the fragmented-packet-drop argument to unconditionally discard all inbound fragmented ESP packets.
```
ORACLE(ipsec-global-config)# options +fragmented-packet-drop
ORACLE(ipsec-global-config)#
```
Use the done and exit to complete configuration.

ACLI show Commands

Two new ACLI commands display filtering statistics.

show security security-policy statistics all, which displays statistics for all filtering policies
show security security-policy [policyName], which displays statistics for a specific filtering policy

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.

From superuser mode, use the following command sequence to access  threshold-crossing-alert-group configuration mode. While in this mode, you configure threshold-crossing-alert-group configuration elements.
```
ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# threshold-crossing-alert-group
ORACLE(threshold-crossing-alert-group)#
```
Use the name parameter to provide a unique identifier for this  threshold-crossing-alert-group instance.
name enables the creation of multiple threshold-crossing-alert-group instances.
```
ORACLE(threshold-crossing-alert-group)# name ikeTCA
ORACLE(threshold-crossing-alert-group)#
```
Use the threshold-crossing-alert parameter to enter threshold-crossing-alert configuration mode. While in this mode, you create specific TCA types and associated values.
```
ORACLE(threshold-crossing-alert-group)# threshold-crossing-alert
ORACLE(threshold-crossing-alert)#
```
Use the type parameter to specify the TCA type.
Supported values are:
- ike-failed-auth — (the default) tracks authentication failures
- ipsec-tunnel-removal — tracks the destruction of IPsec tunnels
- ike-dpd — tracks the detection of dead DPD peers
```
ORACLE(threshold-crossing-alert)# type ike-dpd
ORACLE(threshold-crossing-alert)#
```
Use the critical parameter to specify the critical threshold level.
The default value (0) indicates that the threshold is not configured.
```
ORACLE(threshold-crossing-alert)# critical 100
ORACLE(threshold-crossing-alert)#
```
Use the reset-critical parameter to specify the value at which the critical level is replaced with the next lowest configured threshold level (major, minor, or clear, depending on configuration values).
The default value (0) indicates that the threshold is not configured.
```
ORACLE(threshold-crossing-alert)# reset-critical 90
ORACLE(threshold-crossing-alert)#
```
Use the major parameter to specify the major threshold level.
The default value (0) indicates that the threshold is not configured.
```
ORACLE(threshold-crossing-alert)# major 80
ORACLE(threshold-crossing-alert)#
```
Use the reset-major parameter to specify the value at which the major level is replaced with the next lowest configured threshold level (minor or clear, depending on configuration values).
The default value (0) indicates that the threshold is not configured.
```
ORACLE(threshold-crossing-alert)# reset-major 50
ORACLE(threshold-crossing-alert)#
```
Use the minor parameter to specify the minor threshold level.
The default value (0) indicates that the threshold is not configured.
```
ORACLE(threshold-crossing-alert)# minor 0
ORACLE(threshold-crossing-alert)#
```
Use the reset-minor parameter to specify the value at which the minor level is replaced with the next lowest configured threshold level (clear).
The default value (0) indicates that the threshold is not configured.
```
ORACLE(threshold-crossing-alert)# reset-minor 0
ORACLE(threshold-crossing-alert)#
```
If required, repeat Steps 4 through 10 to add other TCA types to the current threshold-crossing-alert-group configuration element.

The threshold-crossing-alert-group configuration element can contain a maximum of three individual threshold-crossing-alerts, one of each supported type.
Use done, exit, and verify-config to complete configuration of the  threshold-crossing-alert-group configuration element.
If necessary, repeat Steps 1 through 12 to configure additional  threshold-crossing-alert-group configuration elements.
From superuser mode, use the following command sequence to access ike-config configuration mode. While in this mode, you configure IKEv2 interface parameters.
```
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#
```
Use the optional threshold-crossing-alert-group-name parameter to assign an existing threshold-crossing-alert-group configuration element to this IKEv2 interface.
```
ORACLE(ike-interface)# threshold-crossing-alert-group-name ikeTCA
ORACLE(ike-interface)#
```
Use done, exit, and verify-config to complete configuration of the TCA.

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® Enterprise 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

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.9.X (apSecurityIkeInterfaceInfoTable), where X specifies the interface index. For example, the SNMP MIB for the Current Child SA Pairs is 1.3.6.1.4.1.9148.3.9.1.9.X.33, where X specifies the interface index.

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® Enterprise 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® Enterprise 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

TCA Traps

TCAs generate SNMP traps to report crossing of threshold levels, or to clear threshold levels.

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

IKEv1 Protocol

IKEv1 Configuration

IKEv1 Global Configuration

IKEv1 Interface Configuration

IKEv1 Security Association Configuration

IPsec Security Policy Configuration

IKEv2 Protocol

IKEv2 Support

IKEv2 Global Configuration

RADIUS Authentication

Configuring RADIUS Authentication

Configure a RADIUS Server

Configure a RADIUS Authentication Servers List

Tearing Down IPsec Tunnels

Enable RADIUS Authorization

Local Address Pool Configuration

Data Flow Configuration

Local Address Pool Configuration

Persistent Tunnel Addressing

Persistent Tunnel Addressing Configuration

ike-key-id Configuration

Configuring IKEv2 Interfaces

EAP-based Authentication

EAP Authentication Methods

Multiple Authentication

IPv6 Inner Tunnel Address Assignment

EAP-only Authentication

EAP-only Authentication Configuration

Debugging IKEv2 IPsec Tunnel Establishment

Enabling/Disabling Targeted Debugging

High Availability Caveat

Configure an IKEv2 Interface

IPsec Security Policy Configuration

IPsec SA Configuration

Security Policy Configuration

Enable Tunnel Pass-Through

IPSec SA Rekey on Sequence Number Overflow

IPSec SA Rekey on Sequence Number Overflow Configuration

Pre-Populated ARP Table

Pre-Populate An Interface-Specific ARP Table

Configure Dead Peer Detection

Certificate Revocation Lists

CRL-Based Certificate Verification

Configure CRL Certificate Verification

SNMP Traps

Configuring Manual CRL Updates

Online Certificate Status Protocol

OCSP-Based Certificate Verification

Configure OCSP Certificate Verification

SNMP Traps

Enable Certificate Verification on an IKEv2 Interface

Threat Protection

IKEv2-Based DDoS Attacks

Constructing an IKEv2 Access Control Template

Assigning an Access Control Template to an IKEv2 Interface

SNMP Trap

High Availability

Configuring White and Black Lists with Access Control

Configuring White Lists

EAP-SIM Protocol Overview

IMSI/MAC Filtering

Configure IMSI/MAC White Lists

Configure Black Lists

Assign a White List or Black List to an IKEv2 Interface

White List/Black List Interaction

Viewing Security IKE Statistics

Stateless Firewall

ICMP Filtering

ICMP Policy Configuration

SCTP Filters

SCTP Policy Configuration

Source Routing Packets

Fragmented Packets

ACLI show Commands

Threshold Crossing Alert Configuration

IKEv2 Interface Management

IKEv2 Protocol Operations

IKEv2 Negotiation Errors

RADIUS Protocol Operations

Diameter Protocol Operations

Enable Tunnel  Pass-Through