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.

  1. Configure IKEv1 global parameters.
  2. Optionally, enable and configure Dead Peer Detection (DPD) Protocol.
  3. Configure IKEv1 interfaces.
  4. Configure IKEv1 Security Associations (SA).
  5. Assign the IKEv1 SA to an IPsec Security Policy.

IKEv1 Global Configuration

To configure global IKEv1 parameters:

Note:

DPD only works with IKEv2.
  1. 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)#
  2. Use the ike-version parameter to specify IKEv1.

    Use 1 to specify IKEv1 operations.

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

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

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

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

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

  8. Use the optional phase1-dh-mode parameter to specify the Diffie-Hellman Group used during IKE Phase 1 negotiation.
    • first-supported — as responder, use the first supported 
Diffie-Hellman group proposed by initiator

      Note:

      Diffie-Hellman groups determine the lengths of the prime numbers exchanged during the symmetric key generation process.
    • dh-group5 — as initiator, propose Diffie-Hellman group 5 (1536-bit)
    • dh-group14 — as initiator, propose Diffie-Hellman group 14 (2048-bit)
    • dh-group15 — as initiator, propose Diffie-Hellman group 15 (3072-bit)
    • dh-group16 — as initiator, propose Diffie-Hellman group 16 (4096-bit)
    • dh-group17 — as initiator, propose Diffie-Hellman group 17 (6144-bit)
    • dh-group18 — as initiator, propose Diffie-Hellman group 18 (8192-bit)
  9. 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.

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

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

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

  13. Use the optional phase2-exchange-mode parameter to specify the Diffie-Hellman group used in Phase 2 negotiations.
    • phase1-group — (the default) use the same Diffie-Hellman group as used during Phase 1 negotiation
    • 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.
    • dh-group5 — as initiator, propose Diffie-Hellman group 5 (1536-bit)
    • dh-group14 — as initiator, propose Diffie-Hellman group 14 (2048-bit)
    • dh-group15 — as initiator, propose Diffie-Hellman group 15 (3072-bit)
    • dh-group16 — as initiator, propose Diffie-Hellman group 16 (4096-bit)
    • dh-group17 — as initiator, propose Diffie-Hellman group 17 (6144-bit)
    • dh-group18 — as initiator, propose Diffie-Hellman group 18 (8192-bit)
  14. 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.

  15. Use done, exit, and verify-config to complete configuration of IKEv1 global parameters instance.

IKEv1 Interface Configuration

To configure IKEv1 interface parameters:

  1. 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)#
  2. Use the state parameter to enable or disable this IKE interface.
  3. Use the version parameter to specify version 1 for this IKE interface.
  4. Use the address parameter to specify the IPv4 address of the interface.
  5. Use the realm-id parameter to specify the realm that contains the IP address assigned to this IKEv1 interface.
  6. Use the ike-mode parameter to specify the operational mode, either responder (the default) or initiator.
  7. 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.

  8. 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
    Recommendations:
    • Because smaller values impact performance, the minimum recommended value is 200.
    • The maximum recommended value for rekeying IKE SA connections is 24 hours (86400 seconds).
    • The initiator and responder must not have the same rekey value. A gap of at least 100 seconds is recommended.
  9. 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
    Recommendations:
    • Because smaller values impact performance, the minimum recommended value is 200.
    • The maximum recommended value for IPsec SA connections is 8 hours (28800 seconds).
    • The initiator and responder must not have the same rekey value. A gap of at least 100 seconds is recommended.
  10. v1-rekey—(Optional) Enable or disable the automatic re-keying of expired IKEv1 or IPsec SAs on this IKEv1 interface.
  11. 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.

  12. Use done, exit, and verify-config to complete configuration of IKEv1 interface.
  13. 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:

  1. Access the ike-sainfo configuration mode.
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-sainfo
ORACLE(ike-sainfo)#
  2. Use the required name parameter to provide a unique identifier for this ike-sainfo instance.

    name enables the creation of multiple ike-sainfo instances.

  3. Use the security-protocol parameter to specify the IPsec security (authentication and encryption) protocols supported by this SA.

    The following security protocols are available:

    • ah
    • esp
    • esp-auth (default)

    Refer to the following figures for additional details.

    Figure 14-1 AH Transport Mode

    AH Transport Mode

    Figure 14-2 AH Tunnel Mode

    AH Tunnel Mode

    Figure 14-3 ESP Transport Mode

    ESP Transport Mode

    Figure 14-4 ESP Tunnel Mode

    ESP Tunnel Mode
    ORACLE(ike-sainfo)# security-protocol esp
  4. Use the auth-algo parameter to specify the authentication algorithms supported by this SA.

    The following authentication protocols are available:

    • any
    • aes-xcbc
    • sha2-256
    • sha2-384
    • sha2-512 (default)
    ORACLE(ike-sainfo)# auth-algo sha2-512
  5. Use the encryption-algo parameter to specify the encryption algorithms supported by this SA.

    The following encryption protocols are available:

    • any
    • aes-ctr
    • aes (default)
    ORACLE(ike-sainfo)# encryption-algo aes
  6. 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
  7. 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)#
  8. 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 *
  9. Use done, exit, and verify-config to complete configuration of IKEv1 SA.
  10. 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.

  1. 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)#
  2. Use the required ike-sainfo-name parameter to assign an IKv1 SA to this IPsec Security Policy.
  3. 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 Communications Session Border Controller (SBC) supports version 2 of the Internet Key Exchange (IKE) protocol. IKEv2 provides an initial handshake in which IKE peers negotiate cryptographic algorithms, mutually authenticate, and establish session keys to create an IKEv2 Security Association (SA) and an IPsec SA.

Key elements of IKEv2 support include:

  • Peering/SIP Trunking solutions and access-side use cases
  • Mutual authentication between the SBC and its peers, including:
    • IKE rekey
    • Dead Peer Detection (DPD)
    • Initiator mode
    • Responder mode
  • Per-interface IKEv2 configuration
  • Simultaneous support of IKEv1 and IKEv2 protocols
  • Either tunnel or transport mode supported per IKE interface
  • Transcoding
  • Separate interfaces and IP addressing for SIP and IKE for related traffic
  • Certificate-based authentication during IKEv2 tunnel establishment
  • Multiple endpoints beyond tunnel remote address
  • Single or Multiple PSKs over a single IKE interface

With respect to IKE, if the peer does not support any of the encryption, hashing and integrity algorithms and Diffie Hellman groups supported by the SBC, it rejects the IKEv2 establishment. With respect to IPsec, if the peer does not support any of the encryption, hashing and integrity algorithms supported by the SBC, it does not create the child SA.

This can be implemented by removing these from the default list but allow manual configuration to add support.

At the IKEv2 global configuration level, users can do the following:

  1. Configure IKEv2 global parameters.
  2. Configure a default certificate profile.
  3. Configure one or more RADIUS authentication servers (optional).
  4. Configure one or more RADIUS authorization servers (optional).
  5. Configure the default address pool (optional).
  6. 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.

  1. Access the ike-config configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-config
  2. state—Set to enable.
  3. ike-version—Select the IKE protocol version 2.

    WARNING:

    Enabling version 2 in the ike-config element disables version 1 globally.
  4. 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)
  5. udp-port—Set to 500.
  6. 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.

  7. v2-ike-life-secs—Specify the default lifetime (in seconds) of the IKEv2 SA.

    Allowable values are within the range 1800 through 999999999.

  8. v2-ipsec-life-secs—Specify the default lifetime (in seconds) for the IPsec SA.

    Allowable values are within the range 1 through 999999999.

  9. v2-rekey —Enable or disable the re-keying of expired IKEv2 or IPsec SAs.

    When v2-rekey is enabled, the SBC initiates a new negotiation to restore an expired IKEv2 or IPsec SA. The SBC makes a maximum of three retransmission attempts before abandoning the re-keying effort.

  10. anti-replay —(Optional) Enable or disable anti-replay protection on IPsec SAs.
  11. 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.

  12. eap-bypass-identity—(Optional) Specify whether or not to bypass the EAP identity phase.
  13. 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).

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

  15. 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).

  16. 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
  17. 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.

  18. 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).

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

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

  21. 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
  22. account-group-list—(Optional) Designate one or two existing IPsec accounting groups as available to support IPsec accounting transactions.
  23. Type done.
Multiple PSKs per IKE Interface

You can configure the SBC to support multiple pre-shared keys (PSKs) on a single IKE interface. By allowing these multiple PSK authentications, you can support multiple IKE sessions on that interface using unique PSKs. Both symmetric and asymmetric PSK deployments benefit from this capability. You accomplish this by attaching authorization configuration directly to SAs instead of the IKE interface.

A single PSK applies to an entire interface when you configure it within the shared-password parameter in the ike-interface element. The SBC associates this PSK with the ike-interface IP address. The SBC uses the IP associated with the ike-interface as its identity for the ID payload, and the PSK present in the shared-password field as the secret for authentication.

Note:

The ike-config also has a shared-password parameter, which the system uses globally if there is no shared-password in the ike-interface.

To configure this feature, you perform steps that are equivalent to configuring for a single PSK. In addition to these steps, you also define additional ike-key-id objects and assign them to the local-id-profile and remote-id-profile parameters in the applicable ike-sainfo elements.

  • The local-id-profile refers to a unique ike-key-id, which contains the identity and PSK for the SBC.
  • The remote-id-profile refers to a unique ike-key-id, which contains the identity and PSK for the remote device.

This allows you to establish multiple PSKs by associating the security associations with:

  • IP addressing—From the ike-sainfo tunnel addresses
  • Identity for the ID payload—From the key-id in the ike-key-id
  • The secret for authentication—From the presharedkey in the ike-key-id

For this feature to operate properly, the local-id-profile and remote-id-profile must refer to different ike-key-id elements. This provides distinct support for asymmetric-psk deployments. Separate profiles are also required for symmetric-psk deployments because the SBC key-id must be different from the remote user’s key-id, even if the PSKs (passwords) are the same.

If you do not configure either a local-id-profile, remote-id-profile or both, the system uses the password from the ike-interface or ike-config for authentication in the applicable direction (or both directions).

This feature also requires that you configure the id-type parameter in the ike-key-id to the correct key-ID type. Potential values include:

  • IPv4—Version 4 address
  • IPv6—Version 6 address
  • KEY-ID—If you configure the id-type with an ID_KEY_ID value, that value must be 1-128 alphanumeric characters, and can include the '_','.' or '-' characters. This string may not begin with the '.' or '-' characters.

The SBC checks your configuration when you run verify-config and informs you of the following potential multi-PSK errors:

  • The local-id-profile and remote-id-profile are the same.
  • The presharedkey parameter in the ike-key-id is left empty.
  • The key-id value does not match the IPv4 or IPv6 id-type.

Reporting

You can see connections during troubleshooting procedures using the show security ike sad ike-interface <IP addr> all command during troubleshooting procedures. 

ORACLE# show security ike sad ike-interface 12.16.23.24 all
Displaying the total (1) number of entries may take long and could affect system
performance.
Continue? [y/n]?: y
Peer: 12.16.23.25:4500 (NAT: Yes) Host: 12.16.23.24 State: Up
IKEv1 Cookies: 0x7f88c01a9e1e3e76[I] 0x02f088ad845d9640[R] rekeying in 194 seconds
Child Peer IP: 12.16.23.26:0 Child SPI: 118247482[I] 3363465612[O] Protocol: ESP
TUNNEL Mode rekeying in 139 seconds
RADIUS Authentication

All EAP-based authentication is performed by RADIUS servers. When such authentication is specified, the Oracle Communications Session Border Controller operates as a relay between the remote IKVv2 peer and a RADIUS authentication server.

Configuring RADIUS Authentication

RADIUS authentication support requires:

  • configuration of a pool of RADIUS authentication servers, with each server configuration record providing all values required for server access
  • configuration of a RADIUS Authentication Servers List designating specific pool member as being available for authentication purposes
  • assignment of the RADIUS Authentication Servers List to the authentication configuration object
Configure a RADIUS Server
  1. Access the radius-servers configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# authentication
ORACLE(authentication)# radius-servers
ORACLE(radius-servers)#
  2. 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.
  3. authentication-methods—Specify the authentication methods supported by this RADIUS authentication server.
    Valid values are:
    • pap
    • chap
    • mschapv2
    • eap
    • all
  4. address—Specify the IP address of this RADIUS authentication server.
  5. port—Specify the remote port monitored for RADIUS authentication requests.
    Valid values are:
    • 1645
    • 1812
  6. realm-id—Identify the realm that provides transport services to this RADIUS authentication server.
  7. secret—Specify the shared secret between the Oracle Communications Session Border Controller and this RADIUS authentication server.
  8. nas-id—Provide a string that uniquely identifies the SBC to this RADIUS authentication server.
    For example: 
    ORACLE(radius-servers)# nas-id nas-id-170-30-0-1
ORACLE(radius-servers)#
  9. retry-limit—Specify the number of times the SBC retransmits an unacknowledged authentication request to this RADIUS authentication server.
    • Min: 1
    • Max: 5
  10. retry-time—Specify the interval (in seconds) between unacknowledged authentication requests.
    • Min: 5
    • Max: 10
  11. dead-time—Specify the length (in seconds) of the quarantine period imposed an unresponsive RADIUS authentication server.
    • Min: 10
    • Max: 10000
  12. maximum-sessions—Specify the maximum number of outstanding sessions for this RADIUS authentication server.
    • Min: 1
    • Max: 255
  13. class—Select the RADIUS authentication server class, either primary or secondary.

    The SBC 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 SBC uses a round-robin strategy to distribute authentication requests among available primaries.

  14. Type done to save your configuration.
  15. If necessary, configure additional RADIUS authentication servers.
Configure a RADIUS Authentication Servers List
  1. Access the auth-params configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# auth-params
ORACLE(auth-params)#
  2. name—Provide a unique name for this RADIUS Authentication Servers List.
  3. 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)#
  4. Type done to save your configuration.
  5. If necessary, configure additional RADIUS Authentication Servers Lists.
  6. Access the authentication configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# authentication
ORACLE(authentication)#
  7. ike-radius-params-name—Assign a previously configured RADIUS Authentication Servers List to the authentication configuration element.
  8. 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 Communications Session Border Controller responds to a Disconnect-Request message (as defined in RFC 5176, Dynamic Authorization Extensions to Remote Authentication Dial-In User Service) received from a configured RADIUS server.

The SBC parses the received Disconnect-Request for User-Name and Framed-IP-address attribute values. If the User-Name value matches the authenticated EAP identity, and the Framed-IP-address value matches the inner IP address assigned to the authenticated endpoint, the SBC deletes the IPsec tunnel described by the received values. Tunnel deletion is reported to the RADIUS server with a Disconnect-ACK message, which, in conformity to Section 3.5 of RFC 5176, contains an Error Cause of 201 indicating Residual Session Context Removed.

If the IPsec tunnel cannot be deleted because of faulty/incorrect User-Name and/or Framed-IP-address values, the SBC returns a Disconnect-NACK message, which, in conformity to Section 3.5 of RFC 5176, contains an Error Cause of 404 indicating Invalid Request.

Enable RADIUS Authorization

Complete RADIUS authorization configuration by enabling RADIUS authorization on an IKEv2 interface.

  1. Access the ike-interface configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#
  2. Use the select command to specify the target interface.
  3. authorization—Enable RADIUS authorization on the selected interface.
  4. Type done to save your configuration.
  5. 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 Communications Session Border Controller). Refer to Section 2.19 of RFC 7296, Internet Key Exchange (IKEv2) Protocol, for a description of the request process. Procuring such a local IP address ensures that traffic returning to the endpoint is routed to the SBC, and then tunneled back to the endpoint. Local address pools provide the source of these addresses available for temporary endpoint lease.

After address assignment from the local address pool, the endpoint retains rights to that IP address for the tunnel lifetime. Tunnels are terminated either by an INFORMATIONAL exchange, defined in Section 1.4 of RFC 7296, or by expiration of the tunnel SAs as specified by the v2-ike-life-seconds and v2-ipsec-life-seconds configuration parameters. In either case, a subsequent request for an assigned IP address may, or may not result, in the assignment of the previous IP address. However, the SBC can be configured to ensure that a prematurely terminated tunnel, resulting for example from the reset or re-boot of the remote IP peer, can be restored with that previous address. Refer to Persistent Tunnel Addressing in this chapter for operational and configuration details.

During the IKE_AUTH request phase, the IKEv2 initiator can use the Configuration payload in conjunction with either the INTERNAL_IP4_DNS or INTERNAL_IP6_DNS attribute to request the addresses of DNS providers from the SBC. In environments where authorization is performed by a RADIUS AAA server, there are two potential sources of DNS information: local SBC DNS configuration elements, and external RADIUS servers that may provide DNS information in the Access-Accept packet that concludes a successful authentication effort. The source of DNS information provided by the SBC to an IKEv2 peer is subject to user configuration.

A RADIUS source of DNS information is enabled by support for certain Microsoft vendor-specific RADIUS attributes specified in RFC2548, Microsoft Vendor-Specific RADIUS Attributes. Operationally, the SBC extracts the values of the 
MS-Primary-DNS-Server and MS-Secondary-DNS-Server attributes from an 
Access-Accept packet and returns these values to the IKEv2 initiator.

When the DNS information is from external source, the SBC installs a NAT flow (a static traffic path) that provides access to the DNS server. The NAT flow is calculated based on the location of the DNS server IP returned from RADIUS AAA server and configured realm information.

Configuration of DNS information services takes place at the local address pool and IKEv2 interface levels.

Data Flow Configuration

If you need to configure address pools, first configure data flows and then assign them to a specific local address pool. A data flow establishes a static route between a remote IKEv2 peer and a core gateway or router which provides routing services after the associated traffic exits the Oracle Communications Session Border Controller.

  1. Access the data-flow configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# data-flow
ORACLE(data-flow)#
  2. name—Provide a unique identifier for this 
data-flow instance.
  3. realm-id—Identify the realm that supports 
data-flow upstream traffic, that is traffic toward the network core.
  4. 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 SBC 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
  5. upstream-rate—Specify the allocated upstream bandwidth.
    • Min: 0 (allocate all available bandwidth)
    • Max: 122070
  6. downstream-rate—Specify the allocated downstream bandwidth.
    • Min: 0 (allocate all available bandwidth)
    • Max: 122070
  7. 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.
  1. 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)#
  2. name—Provide a unique identifier for this 
local-address-pool instance.
  3. 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.
  4. 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.
  5. data-flow—Identify the data-flow configuration element assigned to this local-address-pool instance.
  6. 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
  7. Type done to save your configuration. and exit to complete configuration of the address-range instance.
  8. If required, add additional address ranges to this 
address-range instance
  9. 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 Communications Session Border Controller can be configured to ensure that a prematurely terminated tunnel can be restored with that previous address.

Tunnels are usually prematurely terminated because of re-boot or reset of the remote endpoint. In either case, the endpoint’s IKEv2 and IPsec SAs are lost and the tunnel no longer exists. From the point of view of the SBC, however, the tunnel remains live. The local IKEv2 and IPsec SAs still exist, and the tunnel remains available in an active state until the expiration of the lifetime timers. Similarly, the IP address assignment from the local address poll remains in effect until timer expiration.

When a crashed endpoint attempts to re-establish a tunnel, it can insert a Notify payload in the initial IKE_AUTH request. The Notify payload contains an INITIAL_CONTACT message that asserts a prior connection between the endpoint and the SBC. When receiving an INITIAL_CONTACT message, the SBC checks for the existence of a live tunnel with the requesting endpoint. If such a tunnel is found, the SBC stores the assigned IP address, tears down the tunnel by removing the supporting IKEv2 and IPsec SAs, and authenticates the endpoint. Assuming authentication succeeds, the SBC, retrieves the previously assigned IP address and returns it to the endpoint.

If a live tunnel is not found (meaning that the tunnel has timed out during the interval between the endpoint reset/re-boot and the new IKE_AUTH), the assertion of a prior connection is ignored, and address assignment is made from the local address pool.

You can use a global configuration option (assume-initial-contact) to enable persistent address processing with or without the reception of an INITIAL_CONTACT message. With this option enabled, all IKE_AUTH requests are processed as if they contained an INITIAL_CONTACT message.

Persistent Tunnel Addressing Configuration

Use the following command sequence to enable persistent tunnel addressing.

  1. Access the ike-config configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-config
  2. options—Enable address persistence. 
    ORACLE(ike-config)# options +assume-initial-contact
ORACLE(local-address-pool)#
  3. 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.

  1. Access the ike-config configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-key-id
ORACLE(ike-key-id)#
  2. name—Provide a unique identifier for this 
ike-key-id instance.
  3. keyid—Specify the keyid to associate an asserted identity with a PSK. 
    ORACLE(ike-key-id)# keyid 172.16.20.20
  4. presharedkey—Specify the string to associate an asserted identity with a PSK. 
    ORACLE(ike-key-id)# presharedkey ************************
  5. id-type—Specify the data type of the keyid parameter you configured above.
    • ipv4 (default)—Specifies that this keyid is IPv4 (ID_IPV4_ADDR)
    • ipv6—Specifies that this keyid is IPv6 (ID_IPV6_ADDR)
    • key—Specifies that this keyid is a string (ID_KEY_ID)
    ORACLE(ike-key-id)# id-type ipv4
  6. Type doneto save your configuration.
  7. Repeat to configure additional ike-keyid instances.

IKEv2 Interface Configuration

After you configure global Internet Key Exchange (IKE) parameters, use the procedures described in the Security chapter to configure and monitor IKEv2 interfaces.

IKEv2 interface configuration includes the following steps.

  1. Configure IKE interface attributes.
  2. Configure Security Associations.
  3. Configure Security Policies.
  4. (Optional) Configure the Dead Peer Detection Protocol.
  5. (Optional) Configure the Online Certificate Status Protocol or Certificate Revocation List Support.
  6. (Optional) Configure Threshold Crossing Alerts.
  7. (Optional) Configure access control allow and block lists.
EAP-based Authentication

RFC 3748, Extensible Authentication Protocol (EAP) describes a flexible and extensible framework that enables authentication services. While the RFC itself describes only a single authentication method, MD5-Challenge, the provided framework support numerous authentication methods.

The current release supports the seven EAP-based authentication methods described in the following sections. Note that for all currently supported EAP authentication methods that the actual authentication is provided by an adjacent RADIUS server. During the EAP-based authentication exchange the SBC functions as a packet relay between the authenticating client(s) and the RADIUS server.

EAP Authentication Methods

EAP supports several authentication methods.

EAP-MD5

EAP-MD5 is based on RFC 1994, PPP Challenge Handshake Authentication Protocol (CHAP). This RFC describes an authentication method that uses an agreed-upon hashing algorithm, a random challenge value, and a shared secret known only to the authenticator and the EAP peer. In the case of EAP-MD5 the hashing algorithm, which produces a 128-bit message-digest or fingerprint, is described in RFC 1321, The MD5 Message-Digest Algorithm.

Using EAP-MD5, authentication of the EAP peer is accomplished as follows.

  1. 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.
  2. 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.
  3. The authenticator performs the same calculation, and compares its results with those reported by the EAP peer.
  4. 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:
  1. 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.
  2. 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.
  3. 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.
  4. The EAP peer performs the same calculation as was performed by the authenticator, and compares its results with those reported by the authenticator. If the results are identical, the peer uses the mutually authenticated connection; otherwise, it drops the connection.

EAP-AKA

The Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA) was devised by the 3GPP (3rd Generation Partnership Project), and made available to the Internet community in RFC 4187. EAP-AKA makes use of the Universal Subscriber Identity Module (USIM), an application resident on the smart card inserted in a 3G mobile phone. The USIM has access to authentication data stored on the smart card.

EAP-SIM

The EAP-SIM Protocol specifies an authentication method for GSM (Global System for Mobile Communication) subscribers. GSM is a second generation mobile standard, and still the most widely used. The authentication method is described in RFC 4186, Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identify Modules (EAP-SIM). Originally developed by the 3GPP, the EAP-SIM protocol specifies an EAP method for authentication and session key distribution using the GSM Subscriber Identity Module (SIM), a smart card installed in the GSM phone.

EAP-TLS

EAP-TLS uses a Transport Layer Security (TLS) handshake, encapsulated within the secure tunnel, to mutually authenticate client and server (or an AAA backend) with certificates. The SBC acts in EAP pass-through mode to communicate the EAP-TLS negotiation between the device and the AAA server.

EAP-TTLS

The EAP-TTLS authentication method is useful when there is no certificate-based infrastructure present for the operator to configure a certificate for each device. EAP-TTLS consists of a Tunneled Transport Layer Security (TTLS) handshake phase (similar to EAP-TLS) and a data phase. During the data phase, the client is authenticated to the server (or the client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks.

EAP-AKA

EAP-AKA' is a small revision to the EAP-AKA (Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement) method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This feature allows its use in EAP in an interoperable manner. Additionally, EAP-AKA' employs SHA-256 instead of SHA-1 as the Secure Hash Algorithm.

Multiple Authentication

The Oracle Communications Session Border Controller supports multiple authentication exchanges during IKEv2 negotiation. These exchanges are defined in RFC 4739, Multiple Authentication Exchanges in the Internet Key Exchange (IKEv2) Protocol. Multiple authentication enables the SBC to engage in an initial certificate-based or shared-secret-based authentication with a remote IKEv2 peer (for example, a femtocell), followed by a subsequent EAP-AKA or EAP-SIM authentication of the remote mobile subscriber.

Multiple authentication exchanges require the use of two specific Notify payloads, MULTIPLE_AUTH_SUPPORTED and ANOTHER_AUTH_FOLLOWS (Notify message type s16404 and 16405) defined in Sections 3.1 and 3.2 of RFC 4739.

Message exchange is as follows. 

Initiator (IKEv2 peer)                                         Responder	
1. HDR, SAi1, KEi, Ni --->
2.        	<--- HDR, SAr1, KEr, Nr, CERTREQ, N (MULTIPLE_AUTH_SUPPORTED)
3. HDR, { IDi, CERT, CERTREQ, {IDr], AUTH, SAi2, TSi, TS2
   (MULTIPLE_AUTH_SUPPORTED) N (ANOTHER_AUTH_FOLLOWS) } --->
4.	                                        <--- HDR, { IDr, CERT, AUTH }
5. HDR, { IDi } --->
6.	                                           <--- HDR, { EAP (Request)}
7. HDR, { EAP (Response) } --->
8.                                           	<--- HDR, { EAP (Request)}
9. HDR, { EAP (Response) } --->
10.	                                          <--- HDR, { EAP (Success)}
11. HDR, { AUTH } --->
12.	                                  <--- HDR, { AUTH, SAr2, TSi, TSr }

In Step 2 the responder advertises support for multiple authentication via the MULTIPLE_AUTH_SUPPORTED Notification Payload.

In Step 3 the initiator advertises support for multiple authentication and, using the ANOTHER_AUTH_FOLLOWS Notification Payload, signals its readiness for such authentication.

Step 4 completes mutual certificate authentication.

In Step 5 the initiator discloses its identity.

In Step 6 the responder initiates the EAP process

In Steps 7 and 8 the initiator and responder exchange authentication information for the remote peer.

In Steps 9 and 10 the initiator and responder exchange authentication information for the mobile subscriber.

Steps 11 and 12 report successful authentication.

IPv6 Inner Tunnel Address Assignment

The Oracle Communications Session Border Controller supports the assignment of IPv6 inner tunnel addresses utilizing an external RADIUS server as the IPv6 address source. During the EAP authentication of an IPsec host, neither the SBC nor the RADIUS authentication server has any knowledge of the traffic type (IPv4 or IPv6) that the IPsec host intends to transmit through the tunnel. Consequently, the RADIUS authentication server may send both IPv4 and IPv6 attributes in the RADIUS 
Access-Accept message, leaving it to the SBC to select the appropriate attribute and ignore the other.

The SBC makes its decision based on the contents of the Configuration Payload received from the IPsec host. If the payload contains an INTERNAL_IP4_ADDRESS attribute, the IPv4 address received in the Access-Accept message is forwarded to the IPsec host. In a similar fashion, if the payload contains an INTERNAL_IP6_ADDRESS attribute, the IPv6 address received in the 
Access-Accept message is forwarded to the IPsec host.

Assignment of IPv6 addresses requires support for the following RADIUS attributes:

  • Framed-IPv6-Prefix (Type 97) — also used in RADIUS accounting
  • Framed-IPv6-Pool (Type 100)

Framed-IPv6-Pool, which can be returned by a RADIUS authentication server in an Access-Accept message, contains the name of an address pool that should be used by the SBC as a source of IPv6 addresses.Use of Framed-IPv6-Pool requires the pre-configuration of the identified address pool on the SBC.

EAP-only Authentication

IKEv2 specifies that Extensible Authentication Protocol (EAP) authentication must be used together with responder authentication based on public key signatures. This is necessary with old EAP methods that provide only unilateral authentication using, for example, one-time passwords or token cards. With EAP-SIM, EAP-AKA, EAP-AKA’, EAP-TTLS, and EAP-TLS, which provide mutual authentication and key agreement, extensible responder authentication for IKEv2 based on methods other than public key signatures can be used. This feature causes the SBC to default to EAP-only authentication without using public-key-based responder authentication unless the operator selects otherwise.

The Extensible Authentication Protocol, defined in RFC3748, is an authentication framework that supports multiple authentication mechanisms. One of the advantages of the EAP architecture is its flexibility. Rather than requiring the authenticator (for example, a wireless LAN access point) to be updated to support each new authentication method, EAP permits the use of a backend authentication server that may implement some or all authentication methods. The SBC uses a backend authentication server (for example, 3GPP AAA) and is in pass-through mode for EAP.

IKEv2 is a component of IPsec used for performing mutual authentication and establishing and maintaining Security Associations (SAs) for IPsec Encapsulating Security Payload (ESP) and Authentication Header (AH). In addition to supporting authentication using public key signatures and shared secrets, IKEv2 also supports EAP authentication. By using EAP, IKEv2 can leverage existing authentication infrastructure and credential databases, such as Home Subscriber Server (HSS), as EAP allows users to choose a method suitable for existing credentials, and also makes separation of the IKEv2 responder (SBC) from the EAP authentication endpoint (back-end Authentication, Authorization, and Accounting (AAA) server) easier. IKEv2 specifies that these EAP methods must also be used together with responder authentication based on public key signatures. For the public key signature authentication of the SBC to be effective, a deployment of Public Key Infrastructure (PKI) is required, which has to include management of trust anchors on all supplicants. This may not realistic in WiFi calling environments, in which the security of the SBC public key is the same as the security of a self-signed certificate. Mutually authenticating EAP methods alone can provide a sufficient level of security.

Because of these reasons, the SBC now defaults to EAP-only authentication without using public-key-based responder authentication unless the operator selects otherwise by disabling the new parameter eap-only-support in the ike-interface configuration element.

EAP-only Authentication Configuration
  1. Access the ike-interface configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#
  2. Select the ike-interface object to edit. 
    ORACLE(ike-interface)# select
<address>:

ORACLE(ike-interface)#
  3. eapOnlyAuthSupport — The default is enabled. Set the value to disabled to use EAP authentication together with responder authentication based on public key signatures.
  4. Type done to save your configuration.
Debugging IKEv2 IPsec Tunnel Establishment

The Oracle Communications Session Border Controller provides details of all IKE endpoints that establish IKEv2/IPsec tunnels. Logging can also be enabled by IP address and 
userid.

In a typical deployment scenario, the IP address can be the public address of a NAT device that communicates with the Oracle Communications Session Border Controller; the user-id can be the user-id of a femtocell or an IKE endpoint residing behind the NAT. The user-id can be an EAP identity exchanged during EAP authentication, or the identity contained in the IDi payload of the initial IKE_AUTH message. Typically the identity in the IDi payload is an IP address, an FQDN, or an address as defined in RFC 822, Standard for the Format of ARPA Internet Text Messages.

Enabling/Disabling Targeted Debugging

Targeted debugging is enabled by the security ike debug-logging peer-ip-userid ACLI command which takes a single string argument in the form ipAddress:userID. For example: 

ORACLE# security ike debug-logging peer-ip-userid 172.16.20.1:12EDE12626719
ORACLE#

With endpoint-specific logging enabled, the log.iked, log.authd, and log.secured files are populated with data pertinent to the target endpoint only and exclude date for all other endpoints. Logging is based on an exact match of the IP address and user-id provided by the argument string.

Note:

This command is expensive and should be used to debug one or two endpoints at a time. The operating system imposes a hard limit of no more than 5 simultaneous targeted debugging sessions.

Use the no form of the command to stop an existing targeted debugging session 

ORACLE# security ike debug-logging peer-ip-userid 172.16.20.1:12EDE12626719 no
ORACLE#

Use the show security ike peer-endpoint-logging ACLI command to display a list of configured debug-logging sessions 

ORACLE# show security ike peer-endpoint-logging 
ORACLE#
IPaddress : Userid
==============
172.16.20.1:12EDE12626719
ORACLE#
High Availability Caveat

Since the security ike debug-logging peer-ip-userid command is expensive, this implementation intentionally does NOT synchronize log data on the active and standby HA devices. Consequently, in the event of a switchover from the active to the standby, no log data is available on the newly active device. To enable debug-logging on the new active device, the user should verify tunnel establishment, and then use security ike debug-logging peer-ip-userid command on the currently active member of the HA pair.

Configure an IKEv2 Interface

This section covers IKEv2 global configuration parameters, omitting IKEv1 parameters. You can override global values set in the ike-config configuration element with values set at the ike-interface level.

  1. Access the ike-interface configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#
  2. state—Enable the IKEv2 interface.
  3. ike-version—Set this attribute to 2.
  4. address—Specify the IPv4 or IPv6 address of the interface. 
    ORACLE(ike-interface)# address 10.0.0.10
  5. realm-id—Specify the realm that contains the IP address assigned to this IKEv2 interface. 
    ORACLE(ike-interface)# realm-id access-10
  6. ike-mode—Specify whether the SBC will act as a responder or initiator.
  7. 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
  8. 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
  9. 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
  10. 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 SBC 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 SBC makes a maximum of three retransmission attempts before abandoning the re-keying effort.

  11. esnsupport—Enable to support Extended Sequence Number (ESN) per RFC 4304.
  12. shared-password—If using the shared-password authentication method, set the shared password.
  13. eap-protocol—(Optional) Set the EAP protocol.
    Available values are:
    • eap-tls
    • eap-leap
    • eap-sim
    • eap-srp
    • eap-ttls
    • eap-aka
    • eap-peap
    • eap-mschapv2
    • eap-fast
    • eap-psk
    • eap-radius-passthru
  14. 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
  15. 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.
  16. 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.
  17. 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"
  18. 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
  19. tunnel-orig-name-list—(Optional) Specify the name the tunnel-origin-params element you want to apply to this IKE interface.
  20. Type done to save your configuration.
  21. 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.

  1. Access the ike-sainfo configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-sainfo
ORACLE(ike-sainfo)#
  2. name—Provide a unique identifier for this ike-sainfo configuration element. 
    ORACLE(ike-sainfo)# name SA-1
  3. 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
  4. auth-algo—Specify the authentication algorithms supported by this SA.
    Available protocols are:
    • any
    • aes-xcbc
    • sha2-256
    • sha2-384
    • sha2-512
  5. encryption-algo—Specify the encryption algorithms supported by this SA.
    The default is aes. Available protocols are:
    • any—Choose any
    • aes—AES with CBC mode
    • aes-ctr—AES with counter mode
  6. 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.
  7. 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
  8. 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 *
  9. local-id-profile—Enter the name of the applicable local ike-key-id element for this ike-sainfo element. That ike-key-id element contains information needed to associate the SBC asserted identity with a PSK.
  10. remote-id-profile—Enter the name of the applicable remote ike-key-id element for this ike-sainfo element. That ike-key-id element contains information needed to associate the remote station's asserted identity with a PSK.
  11. Type done to save your configuration.
  12. If necessary, configure additional IPsec SAs.
Security Policy Configuration

Use the following procedure to define an IPsec Security Policy.

  1. Access the security-policy configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ipsec
ORACLE(ipsec)# security-policy
ORACLE(security-policy)#
  2. name—Identify this IPsec Security Policy. 
    ORACLE(security-policy)# name requireIPsec
  3. 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
  4. priority—(Optional) Assign a priority to this IPsec Security Policy.
    • Highest priority: 0
    • Lowest priority: 3071
  5. 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
  6. direction—Identity the traffic streams subject to the processing specified by the action parameter.
    Available values are:
    • in
    • out
    • both
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. ike-sainfo-name—Assign an IPsec data SA to this Security Policy.
  14. 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

  1. Configure IPv4 allow policy for IKE protocol traffic
  2. Configure IPv4 ipsec policy for media traffic
  3. Configure the IKEv2 IPv4 interface with an IPv4 local address pool, or
  4. Configure the RADIUS server to return a Framed-IP-Address and/or 
Framed-IP-Netmask attribute

Pass-through IPv6 traffic via an IPv6 tunnel

  1. Configure IPv6 allow policy for IKE protocol traffic
  2. Configure IPv6 ipsec policy for media traffic
  3. Configure the IKEv2 IPv6 interface with an IPv6local address pool, or
  4. Configure the RADIUS server to return a Framed-IPv6-Prefix or 
Framed-IPv6-Pool attribute

Pass-through IPv4 traffic via an IPv6 tunnel

  1. Configure IPv6 allow policy for IKE protocol traffic
  2. Configure IPv4 ipsec policy for media traffic
  3. Configure the IKEv2 IPv6 interface with an IPv4 local address pool, or
  4. Configure the RADIUS server to return a Framed-IP Address and/or 
Framed-IP-Netmask attribute

Pass-through IPv6 traffic via an IPv4 tunnel

  1. Configure IPv4 allow policy for IKE protocol traffic
  2. Configure IPv6 ipsec policy for media traffic
  3. Configure the IKEv2 IPv4 interface with an IPv6local address pool, or
  4. Configure the RADIUS server to return a Framed-IPv6-Prefix or 
Framed-IPv6-Pool attribute
IPSec SA Rekey on Sequence Number Overflow

The Oracle Communications Session Border Controller establishes a new IPSec security association (SA) when the counter for the outbound 32-bit Sequence Number (SN) or the 64-bit Extended Sequence Number (ESN) overflows.

The SN or ESN counter is incremented for every outbound packet. These counters can overflow when the SBC is handling packet intensive services such as video streaming or long duration calls. In accordance with RFCs 4303 and 7296, the SBC establishes new security associations, as part of rekeying, before the SN or ESN counters can roll over. It does this through the use of two parameters in the ipsec-global-config configuration element: rekey-on-sn-overflow, the default for which is enabled, and sn-rekey-threshold, which identifies the threshold for rekeying security associations as a percentage of the counter capacity and for which the default is 95.

There are four ACLI commands you can use to monitor SN and ESN counter overflows:

show datapath etc-stats ppms ipsec

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
  1. 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)#
  2. Select the ipsec-global-config object to edit. 
    ORACLE(ipsec-global-config)# select
ORACLE( ipsec-global-config)#
  3. 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.
  4. 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.
  5. 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 Communications Session Border Controller core interface. In these instances, the SBC receives the tunneled packet, and masks the received IP destination address against its own local addresses to determines if direct delivery is possible. If so, the SBC issues an ARP request to obtain the physical destination address.

This process can be expedited by pre-populating the interface-specific ARP table with a list of commonly accessed core network host reachable by that interface. With the ARP table pre-populated with IP addresses, the ARP process issues ARP requests at 5 second intervals until a response is received. Once the pre-populated IP address has been resolved, periodic ARP refreshes are used to maintain the currency of the resolution.

Pre-Populate An Interface-Specific ARP Table
  1. Access the network-interface configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# network-interface
ORACLE(network-interface)
  2. 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)#
  3. 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
  4. 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.

  5. 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
        ...
  6. 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.

  1. Access the dpd-params configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# dpd-params
ORACLE(dpd-params)#
  2. name—Provide a unique identifier for this 
dpd-params instance. 
    ORACLE(dpd-params)# name ikeDPD
  3. max-loop—Specify the maximum number DPD peers whose liveliness is examined every dpd-interval period.

    Periodic liveliness is tested by the Oracle Communications 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
  4. max-retrans—Specify the maximum number of times that the SBC, 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
  5. 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
  6. 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.

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

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

  10. Type done to save your configuration.
  11. If necessary, configure additional dpd-params configuration elements.
  12. Access the ike-interface configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#
  13. dpd-params-name—Enable Dead Peer Detection on this IKEv2 interface. 
    ORACLE(ike-interface)# dpd-params-name ikeDPD
  14. 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 Communications Session Border Controller.

When authentication of remote IKEv2 peers is certificate-based, you can enable CRL usage on IKEv2 interfaces to verify certificate status.

CRL-Based Certificate Verification

This section provides instruction on using the ACLI to configure periodic retrieval of CRLs.

Configuration of CRL-based certificate verification is a three-step process.

  1. Specify the information and cryptological resources required to access one or more CRL sources.
  2. If not already done, enable CRL usage on an IKEv2 interface.
  3. 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.

  1. Access the cert-status-profile configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# cert-status-profile
ORACLE(cert-status-profile)#
  2. name—Provide a unique name for this profile.
  3. type—Select the certificate revocation check method.
    Available values are:
    • OCSP
    • CRL
  4. 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 SBC uses the IP address and ignores the host-name value.
  5. 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
  6. realm-id—Specifies the realm used to request and receive CRLs.
    In the absence of an explicitly configured value, the SBC 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.
  7. 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.

  8. 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
  9. dead-time—Specify the quarantine period imposed on an unavailable CRL source.
    The default is 0.
    • Min: 0
    • Max: 3600
  10. 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.

  11. Type done to save your configuration.
  12. If necessary, configure additional cert-status-profile configuration elements.
SNMP Traps

An SNMP trap is thrown, and a major alarm generated, if the Oracle Communications Session Border Controller is unable to retrieve a CRL from the server. This trap includes the server’s FQDN, assuming that the FQDN has been identified during the configuration process, the server’s IP address, the reason for the failure, and the time of the last successful CRL retrieval, with the time expressed as the number of seconds since midnight January 1, 1970.

A second SNMP trap is thrown when the SBC successfully retrieves a CRL. This trap includes the server’s FQDN, assuming that the FQDN has been identified during the configuration process, and the server’s IP address. The issue of this trap also clears any associated major alarm.

Configuring Manual CRL Updates

The ACLI provides the ability to perform an immediate manual refresh of one or more CRLs.

Use the following command to refresh a single CRL.

ORACLE# load-crl local-file <fileName>

where <fileName> is a remote filepath specified by the crl-list attribute.

Use the following command to refresh all CRLs.

ORACLE# load-crl local-file all

Use the following command to refresh all CRLs from a specific CRL source.

ORACLE# load-crl cert-status-profile <certStatusProfileName>

where <certStatusProfileName> references the certificate-status-profile configuration element that contains the CRL source IP address or FQDN.

Use the following command to refresh all CRLs.

ORACLE# load-crl cert-status-profile all
Online Certificate Status Protocol

The Online Certificate Status Protocol (OCSP) enables users to determine the revocation state of a specific certificate. Because OCSP ensures access to the freshest CRL, it can provide a more timely source of revocation information than is possible with dynamically or manually loaded CRLs. Guaranteed access to the most recent CRL, however, comes at the expense of increased traffic: a single request/response exchange for each revocation check.

If the OCSP responder returns a status of good, the certificate is accepted and authentication succeeds. If the OCSP responder returns a status other than good, the certificate is rejected and authentication fails.

Certificate status is reported as

  • good—which indicates a positive response to the status inquiry. At a minimum, a positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate’s validity interval.
  • revoked—which indicates a negative response to the status inquiry. The certificate has been revoked, either permanently or temporarily.
  • unknown—which indicates a negative response to the status inquiry. The responder cannot identify the certificate.

When authentication of remote IKEv2 peers is certificate-based, you can enable OCSP on IKEv2 interfaces to verify certificate status.

OCSP-Based Certificate Verification

The following sections provides instruction on using the ACLI to configure OCSP-based certificate verification.

Configuration of OCSP-based certificate verification is a three-step process.

  1. Specify the information and cryptological resources required to access one or more OSCP responders.
  2. Enable OCSP on an IKEv2 interface.
  3. Associate one or more OCSP responders with an IKEv2 interface.
Configure OCSP Certificate Verification
  1. Access the cert-status-profile configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# cert-status-profile
ORACLE(cert-status-profile)#
  2. name—Provide a unique name for this profile.
  3. 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 SBC uses the IP address and ignores the host-name value.
  4. port—Identifies the port monitored by the HTTP server for incoming OCSP requests.

    The port attribute can be safely ignored if the SBC is specified as a FQDN by the host-name attribute, but is required if the SBC is identified by the ip-address attribute.

  5. type—Select the certificate revocation check method.
    Available values are:
    • OCSP
    • CRL
  6. trans-protocol—Retain the default value (http) for trans-protocol attribute, which identifies the transport method used to access the SBC.
  7. 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.
  8. 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.
  9. trusted-cas—A list of certificate configuration objects that identifies the approved DoD-approved CAs that sign SBC 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 SBC (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.

  10. realm-id—Specify the realm used to transmit OCSP requests and receive OCSP responses.

    In the absence of an explicitly configured value, the SBC provides a default value of wancom0, specifying OCSP protocol transmissions across the wancom0 management interface.

  11. 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
  12. dead-time—Specify the quarantine period imposed on an unavailable CRL source.
    The default is 0.
    • Min: 0
    • Max: 3600
  13. Type done to save your configuration.
  14. 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
  1. Access the ike-interface configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#
  2. Select the ike-interface object to edit. 
    ORACLE(ike-interface)# select
<address>:

ORACLE(ike-interface)#
  3. cert-status-check—Enable certificate status checking on this IKEv2 interface.
  4. 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)#
  5. Type done to save your configuration.
Threat Protection

Internet Key Exchange (IKE) v2 threat protection is composed of:

  • IKEv2 DDoS control
  • Allowlist and Blocklist access controls
  • IP-header based firewalls
IKEv2-Based DDoS Attacks

Given its usual location at the network edge, and the two stage negotiation process required for the establishment of IPsec tunnels, the Oracle Communications Session Border Controller can be a target of IKEv2-based DDoS (distributed denial of service) attacks. Such attacks, which seek to overwhelm or monopolize system resources to the detriment of the gateway’s functionality, can take several forms including:

  • prolonging/failing to complete negotiation of the IKEv2 Security Association (SA)
  • prolonging/failing to complete negotiation of the IPsec SA
  • excessive renegotiation/rekeying of an established IKEv2 SA
  • excessive renegotiation/rekeying of an established IPsec SA
  • sabotaging the IKEv2 negotiation by failing to present a valid cookie when required to do so
  • sabotaging the IKEv2 negotiation by failing to present valid credentials when required to do so

The SBC provides protection against DDoS attacks by monitoring IKEv2 signaling traffic from remote endpoints (defined by an IP address:UDP port pair). All endpoints start in the allowed state, meaning that IKEv2 signaling received from the endpoint is accepted as valid by the SBC. A group of policing parameters, and associated counters, provide protection against DDoS attacks by monitoring IKEv2 signaling from individual endpoints. The SBC maintains a set of counters for each endpoint. The counters record instances of suspect traffic, which may indicate malicious intent, and periodically compare endpoint-specific traffic counts to threshold values established by the policing parameters. If endpoint counts meet or exceed threshold values, the SBC places the endpoint in the deny state, and, if they exist, tears down the IKEv2 SA and IPsec SA associated with the endpoint. While in the deny state, the endpoint is quarantined and refused all access to the IKEv2 interface. The endpoint remains quarantined until the expiration of a pre-set timer. At timer expiration, the endpoint is transitioned to the allowed state, and granted IKEv2 interface access.

Configuration of IKEv2 DDOS protection consists of the following steps.

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

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

  1. 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)#
  2. 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)#
  3. 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)#
  4. Use the tolerance-window parameter to specify the interval (in seconds) between checks of endpoint-specific traffic counters.

    At the specified interval, the Oracle Communications 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)#
  5. 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)#
  6. 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)#
  7. 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)#
  8. 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 SBC 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)#
  9. 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)#
  10. 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)#
  11. 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)#
  12. 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)#
  13. Use done, exit, and verify-config to complete configuration of the IKEv2 Access Control Template.
  14. 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.

  1. 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)#
  2. 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)#
  3. 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)#
  4. 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 Communications Session Border Controller. Endpoint deny status, however, is synchronized with the standby.

Support for Allowlists and Blocklists with Access Control

The SBC supports Internet Key Exchange (IKE) v2 access-control allow lists that permit authentication only for a provisioned list of IMSI prefixes or MAC addresses. The SBC also supports block lists that deny authentication to a provisioned list of IMSI prefixes or MAC addresses.

Allowlist Configuration

Use the procedures described in "Threat Protection" only when the EAP-SIM protocol performs authentication. You can disregard this section when the Oracle Communications Session Border Controller uses 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 and MAC Filtering

With EAP-SIM protocol in use, authentication is accomplished by a RADIUS server. Using the Wm interface, the Oracle Communications Session Border Controller passes the received IMSI identity to the RADIUS server. In order to minimize server processing, the SBC provides users with the optional ability to compile IMSI prefix allowlists that filter identities presented for RADIUS authentication. Allowlists are inclusive in that only those identities matching list contents are granted RADIUS access; non-matching identities are summarily rejected by the SBC. The allowlists 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. Allowists 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 and MAC Allowlists

The ike-access-control configuration element defines an allowlist that filters Intenrational Mobile Subscriber Identity (IMSI) or Media Access Control (MAC) identities presented by remote endpoints during the authentication process. Only those identities matching the literal or regular expressions contained in the allowlist are forwarded through the Wm interface to a RADIUS server for authentication.

  1. 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)#
  2. name—Provide a unique identifier. 
    ORACLE(ike-access-control)# name allow_01
  3. state—Enable access control.
  4. identifier—Provide one or more MCC or MCC or MNC match patterns for IMSI-based allowlisting.

    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 allowlisting, 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 allowlist. Assigning an empty allowlist to an IKEv2 interface results in authentication failure for all presented identities.
  5. Type done to save your configuration.
  6. If necessary, configure additional ike-access-control configuration elements.
Configure a Blocklist

A blocklist 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. Blocklists are only applicable for femtocell clients performing EAP authentication to the SBC and are not applicable for clients doing password-based or certificate-based authentication.

  1. 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)#
  2. name—Provide a unique identifier. 
    ORACLE(ike-access-control)# name block_01
  3. state—Enable access control.
  4. blocklisted-dentifiers—Provide one or more MAC-based match patterns for MAC-address-based blocklists.

    The following double-quote delimited list identifies three specific MAC addresses whose authentication is summarily rejected. 

    ORACLE(ike-access-control)# blocklisted-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)# blocklisted-dentifiers "0123456789A^, ^123456789AB"

    For IMSI-based blocklists, this example uses a double-quote delimited list of prefixes separated by spaces, to match Verizon Wireless United States networks. 

    ORACLE(ike-access-control)# blocklisted-dentifiers "310004 310012"

    Note:

    Do not configure an empty blocklist. Assigning an empty blocklist to an IKEv2 interface results in authentication eligibility for all presented identities.
  5. Type done to save the configuration.
  6. If necessary, configure additional ike-access-control configuration elements.
Assign an Allowlist or Blocklist to an IKEv2 Interface
  1. Access the ike-interface configuration element. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# ike-interface
ORACLE(ike-interface)#
  2. Select the ike-interface object to edit. 
    ORACLE(ike-interface)# select
<address>:

ORACLE(ike-interface)#
  3. access-control-name—Identify the allowlist or block list assigned to the current interface. 
    ORACLE(ike-interface)# access-control-name allow_01
  4. Type done to save your configuration.
Allowlist and Blocklist Interaction

Allowlists and blocklists may or may not be assigned to the IKEv2 interfaces. The following rules are used to support implementation of both list types.

  1. If neither an allowlist nor a blocklist are assigned to an IKEv2 interface, all EAP authentication requests are forwarded to a RADIUS authentication server for final determination.
  2. When only an allowlist is assigned to an IKEv2 interface, the incoming EAP identity is to be checked against that allowlist. When the EAP identity is contained in the allowlist, the authentication request is forwarded to a RADIUS authentication server for final determination. If the EAP identity is absent, authentication is denied.
  3. When only a blocklist is assigned to an IKEv2 interface, the incoming EAP identity is checked against that blocklist list. If the EAP identity is contained in the blocklist, authentication is denied. When the EAP identity is absent, the authentication request is forwarded to a RADIUS authentication server for final determination..
  4. If both a allowlist and a blocklist are assigned to an IKEv2 interface, the SBC checks both lists for incoming EAP identity.

    When the EAP identity is contained in the allowlist, and is absent from the blocklist, the authentication request is forwarded to a RADIUS authentication server for final determination.

    When the EAP identity is contained in the blocklist and is absent from the allowlist, authentication is rejected.

    When the EAP identity is present in both lists, the blocklist takes priority and authentication is rejected. This situation will have been previously reported by the verify-config ACLI command.

    When the EAP identity is absent from both lists, the allowlist takes priority. Because the allowlist does not contain the EAP identity, authentication is denied.

View Security IKE Statistics

Use the show security ike statistics ACLI command to view statistics derived from the IKEAuthIDError and BlocklistIKEAuthIDError counters, containing the number of authentication denials due to both allowlist and blocklist filtering.

For detailed information about the show security ike statistics ACLI command, see the ACLI Reference Guide.

Stateless Firewall

The SBC provides enhanced security-policy-based filters that can be applied to data packets coming through IPSec tunnels on the protected interfaces, and to non-IPSec packets on the trusted interfaces. These filters evaluate only the IP header layer, and treat each individual packet as a discrete event. As such, the functionality they provide can be compared to that provided by a stateless firewall.

Available filters are discussed in the following sections.

ICMP Filtering

Internet Control Message Protocol (ICMP) messages can be filtered based on message Type and associated message Codes.

ICMP Policy Configuration

Use the following procedure to define security-policy-based filtering of ICMP packets. This sample policy discards ICMP message type 0, Echo Reply, code 0, Net Unreachable.

  1. 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)#
  2. Use the required name parameter to identify this policy. 
    ORACLE(security-policy)# name deny_icmp-type0_code0
ORACLE(security-policy)#
  3. 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)#
  4. 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)#
  5. 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)#
  6. 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)#
  7. 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)#
  8. 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)#
  9. 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)#
  10. 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 3071 (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)#
  11. 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)#
  12. 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)#
  13. 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)#
  14. 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)#
  15. 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)#
  16. Ignore the ike-sainfo-name parameter.
  17. Use done, exit, and verify-config to complete configuration of the security policy.
  18. 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.

  1. 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)#
  2. \Use the required name parameter to identify this policy. 
    ORACLE(security-policy)# name allow_sctp-ppid_46
ORACLE(security-policy)#
  3. 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)#
  4. 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)#
  5. 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)#
  6. 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)#
  7. 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)#
  8. 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)#
  9. 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)#
  10. 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 3071 (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)#
  11. 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)#
  12. 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)#
  13. Ignore the optional trans-sub-protocol-code-match parameter, which is not currently used for SCTP filter configuration.
  14. 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)#
  15. 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)#
  16. Ignore the ike-sainfo-name parameter.
  17. Use done, exit, and verify-config to complete configuration of the security policy.
  18. Repeat Steps 1 through 17 to configure additional security policies.
Source Routing Packets

The SBC can unconditionally discard all source routed packets at the global level. Source routed packets are identified by the presence of either a Loose Source Route/Record (LSRR) or a Strict Source Route/Record (SSRR) option within the IP header Options header.

Both options have the potential to mask malicious intent. An attacker can use the specified routes to hide the true source of a packet, or to gain access to a protected network. Consequently, such packets are often dropped upon network entry.

Use the following procedure to unconditionally discard all source routed packets.

  1. 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)#
  2. 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)#
  3. Use the done and exit to complete configuration.
Fragmented Packets

The SBC can unconditionally discard all inbound fragmented Encapsulating Security Protocol (ESP) packets using a global option. Refer to Figure 3, ESP Transport Mode, and Figure 5, ESP Tunnel Mode, for ESP details.

Upon reception, the SG re-assembles such packets and then decrypts the re-assembled packet. After decryption, if the decrypted packet is still a fragment, the new option mandates that the packet fragment be discarded in light of the SG’s inability to do a proper policy check on an incomplete message.

Use the following procedure to unconditionally discard all fragmented ESP packets.

  1. 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)#
  2. 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)#
  3. 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.

  1. 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)#
  2. 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)#
  3. 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)#
  4. 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)#
  5. 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)#
  6. 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)#
  7. 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)#
  8. 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)#
  9. 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)#
  10. 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)#
  11. 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.

  12. Use done, exit, and verify-config to complete configuration of the 
threshold-crossing-alert-group configuration element.
  13. If necessary, repeat Steps 1 through 12 to configure additional 
threshold-crossing-alert-group configuration elements.
  14. 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)#
  15. 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)#
  16. 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 Communications Session Border Controller.

The first section, IKEv2 Protocol Operations, describes a series of 32-bit counters that report interface-specific data on various protocol transactions. Protocol operations counter values are available with SNMP, through the ACLI show security ike statistics command, and can also be obtained by subscription to the ike_stats HDR group.

The second section, IKEv2 Negotiation Errors, describes a series of 32-bit counters that report interface-specific errors encountered during IKEv2 negotiations. Negotiation errors counter values are also available with SNMP, through the ACLI show security ike statistics command, and can also be obtained by subscription to the ike-stats HDR group.

The third section, RADIUS Protocol Operations, describes a series of 32-bit counters that report RADIUS-server-specific data. RADIUS protocol operations counter values are also available with SNMP, through the ACLI show radius command, and can also be obtained by subscription to the radius-stats HDR group.

The final section, Diameter Protocol Operations, describes a series of 32-bit counters that report Diameter-server-specific data. Diameter protocol operations counter values are also available with SNMP, and can also be obtained by subscription to the diameter-stats HDR group.

IKEv2 Protocol Operations
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 Communications Session Border Controller. A successful R-U-THERE/ACK exchange establishes availability on the remote IKEv2 peer. counter .11
DPD Response Not Received The number of R-U-THERE messages transmitted on the interface that were not acknowledged within the DPD allowed interval. counter .12
DPD Received The number of all DPD protocol messages received on the interface. counter .13
DPD Retransmitted The number of R-U-THERE messages that were re-transmitted because the original R-U-THERE message was not acknowledged. counter .14
DPD Sent The number of R-U-THERE messages that were sent across the interface, to include retransmitals. counter .15
IKE SA Packets Sent The number of IKEv2 SA packets sent across the interface. counter .16
IKE SA Packets Received The number of IKEv2 SA packets received across the interface. counter .17
IKE SA Packets Dropped The number of IKEv2 SA packets dropped by the interface. counter .18
Authentication Failures The number of authentication failures that occurred after the purported identity of the remote IKEv2 peer was ascertained. counter .19
IKE Message Errors The number of otherwise uncharacterized IKEv2 message errors. counter .20
Authentication ID Errors The number of errors that occurred during the identification stage of the authentication process. counter .21
Certificate Status Requests The number of certificate status requests sent across the interface to an OCSP responder. counter .22
Certificate Status Success The total number of OCSP successes, that is the number of OCSP requests that generated a good status from an OCSP responder. counter .23
Certificate Status Fail The total number of OCSP failures, to include unacknowledged OCSP requests and those requests that generated a revoked or unknown response from an OCSP responder. counter .24
DDoS Sent The number of suspicious, and possibly malicious, endpoints reported by the interface-specific DDoS process (if configured as described in the IKEv2 DDoS Protection section of the Oracle Communications Session Border Controller Essentials guide). counter .25
DDoS Received The number of suspicious, and possibly malicious, endpoints reported by statically provisioned deny lists (as described in SIP Signaling Services and Security chapters of the ACLI Configuration Guide). counter .26
IKE Message Retransmissions The total number of IKEv2 message re-transmissions. counter .27
SA Init Messages Received The total number of IKEv2 message re-transmissions. counter .28
SA Init Message Sent The total number of IKEv2 message re-transmissions. counter .29
SA Establishment Attempts The total number of IKEv2 message re-transmissions. counter .30
SA Establishment Success The total number of IKEv2 SA successfully established on the IKEv2 interface. counter .31
Tunnel Rate Specifies the tunnel establishment rate, in terms of tunnels created per second. Note that this count is available through both an ACLI show command and an SNMP GET operation. gauge .32
IKEv2 Negotiation Errors

The SNMP MIB is formed by appending the value in the SNMP MIB Ending column to 1.3.6.1.4.1.9148.3.9.1.3.X (apSecurityIkeInterfaceStatsEntry), where X specifies the interface index. For example, the SNMP MIB for the CPU Overload Errors is 1.3.6.1.4.1.9148.3.9.1.3.X.3, where X specifies the interface index.

Name Description SNMP MIB Ending
CPU Overload Errors The number of IKEv2 requests that were rejected because of CPU load constraints. .3
Init Cookie Errors The number of all IKEv2 exchanges that failed because of faulty Security Parameter Index (SPI) values. SPIs provide a local SA identifier and are exchanged between IKEv2 peers in the common IKEv2 header and in Notify Payloads. .4
Auth Errors The number of failed IKE_AUTH exchanges, regardless of the specific reason for failure. .5
EAP Access Request Errors The number of authentication failures that occur ed during the EAP access phase. .6
EAP Access Challenge Errors The number of authentication failures that occur ed during the EAP challenge phase. .7
TS Errors The number of CREATE_CHILD_SA exchanges that failed because of faulty TS payload contents, or failure on the part of the remote peers to negotiate the offered traffic selectors. .8
CP Errors The number of IKE_AUTH and/or CREATE_CHILD_SA exchanges that failed because of faulty, unsupported, or unknown Configuration Payload contents. .9
IKE Errors The number of IKE_SA_INIT and/or CREATE_CHILD_SA exchanges that failed because of faulty, unsupported, or unknown Key Exchange Payload contents. .10
Proposal Errors The number of failed negotiations that resulted from the inability to reconcile crytographic proposals contained in the Security Association Payloads exchanged by IKEv2 peers. Security Association Payloads are exchanged during the IKE_SA_INIT, IKE_AUTH, and CREATE_CHILD_SA stages. .11
Syntax Errors The number of failed negotiations, of any type, resulting from otherwise uncharacterized errors. .12
Critical Payload Errors The number of failed negotiations that resulted from the presence of a Critical flag in a payload that could not be parsed, or was not supported. IKEv2 adds a critical flag to each payload header for further flexibility for forward compatibility. If the critical flag is set and the payload type is unrecognized, the message must be rejected and the response to the IKE request containing that payload MUST include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an unsupported critical payload was included. If the critical flag is not set and the payload type is unsupported, that payload must be ignored. .13
RADIUS Protocol Operations

The SNMP MIB is formed by appending the value in the SNMP MIB Ending column to 1.3.6.1.4.1.9148.3.18.1.1.1 (aapRadiusServerStatsEntry). For example, the SNMP MIB for the Server Roundtrip Time is 1.3.6.1.4.1.9148.3.18.1.1.1.3.

Name Description SNMP MIB Ending
Server Roundtrip Time Contains the average round trip time for a response from this RADIUS server. .3
Server Malformed Access Response Contains the number of malformed access responses received on this RADIUS server. .4
Server Access Requests Contains the number of access requests received on this RADIUS server. .5
Server Disconnect Requests Contains the number of disconnect requests received on this RADIUS server. .6
Server Disconnect ACKS Contains the number of acknowledged disconnects on this RADIUS server. .7
Server Disconnect NACKS Contains the number of unacknowledged disconnects on this RADIUS server. .8
Server Bad Authenticators Contains the number of authentication rejections on this RADIUS server. .9
Server Access Retransmissions Contains the number of access retransmitals on this RADIUS server. .10
Server Access Accepts Contains the number of successful authentications on this RADIUS server. .11
Server Timeouts Contains the number of Response timeouts on this RADIUS server. .12
Server Access Rejects Contains the number of unsuccessful authentications on this RADIUS server. .13
Server Unknown PDUTypes Contains the number or unknown/unreadable PDUs received by this RADIUS server. .14
Server Access Challenges Contains the number of Access Challenges on this RADIUS server. .15
Diameter Protocol Operations

The SNMP MIB is formed by appending the value in the SNMP MIB Ending column to 1.3.6.1.4.1.9148.3.13.1.1.2.2.X (apDiamInterfaceStatsTable), where X specifies the diameter server index. For example, the SNMP MIB for the Diameter Messages Sent is 1.3.6.1.4.1.9148.3.13.1.1.2.2.X.3, where X specifies the diameter server index.

Name Description SNMP MIB Ending
Diameter Messages Sent Contains the number of messages sent by this Diameter server. .3
Diameter Messages Sent Failed Contains the number of unacknowledged messages sent by this Diameter server. .4
Diameter Messages Resent Contains the number of messages re-transmitted to this Diameter server. .5
Diameter Messages Received Contains the number of messages received by this Diameter server. .6
Diameter Messages Processed Contains the number of messages processed by this Diameter server. .7
Diameter Connection Timeouts Contains the number of connection timeouts on the Diameter server. .8
Diameter BadState Drops Contains the number of packets dropped because of faulty state on the Diameter server. .9
Diameter BadType Drops Contains the number of packets dropped because of faulty type on the Diameter server. .10
Diameter BadID Drops Contains the number of packets dropped because of faulty ID on the Diameter server. .11
Diameter AuthFail Drops Contains the number of failed authentications on the Diameter server. .12
Diameter Invalid Peer Messages Contains the number of client messages that could not be parsed on the Diameter server. .13
ACLI Show Commands

ACLI show commands

  • display and reset IKEv2 performance and error counters
  • display IKEv2 SA data
  • display IKEv2 TCA data
Performance and Error Counters

Three ACLI commands display and reset IKEv2 performance and error counters.

Use the show security command to display performance and error counters for a specified IKEv2 interface, or for all IKEv2 interfaces. 

ORACLE# show security 192.169.204.15

with a specified interface, displays performance and error counters for the target interface 

ORACLE# show security all

with all, displays performance and error counters for all IKEv2 interfaces

Use the reset ike-stats command to reset (set to 0) performance and error counters for a specified IKEv2 interface, or for all IKEv2 interfaces. 

ORACLE# reset ike-stats 192.169.204.15

with a specified interface, resets performance and error counters for the target interface 

ORACLE# reset ike-stats all

with all, resets performance and error counters for all IKEv2 interfaces

Use the reset ike-mib command to reset (set to 0) MIB-based error counters for all IKEv2 interfaces. 

ORACLE# reset ike-mib

re-sets the MIB-based error counters for all IKEv2 interfaces

IKEv2 and Child SAs

Use the show security command with optional arguments to display IKEv2 and child SA information to include:

  • IP address and port of remote end-point
  • intervening NAT device (yes | no)
  • local IP address
  • tunnel state (up | down)
  • initiator cookie
  • responder cookie
  • remote inner (tunnel) IP address
  • incoming/outgoing Security Parameter Indexes (SPI) of the child SA 
ORACLE# show security ike sad ike-interface 192.169.204.15

with a specified interface address, displays SA information for a single IKEv2 interface 

ORACLE# show security ike sad ike-interface all

with all, displays SA information for all IKEv2 interfaces 

ORACLE# show security ike 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
  • IPsec encryption protocol 
ORACLE# show security ike sad ike-interface <ipAddress> peer <ipAddress> 
ORACLE# show security ike 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 : 17
        Hash : HMAC-SHA-256
        MAC : SHA-256
        Cipher : AES

    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