Key Exchange Protocols
Key exchange protocols enable secure communications over an untrusted network by deriving and distributing shared keys between two or more parties. The Internet Key Exchange (IKEv1) Protocol, originally defined in RFC 2409, provides a method for creating keys used by IPsec tunnels. Session Description Protocol Security Descriptions for Media Streams (SDES), defined in RFC 4568, provides alternative methods for creating keys used to encrypt Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP) transactions.
Each of these protocols is described in the following sections.
IKEv1 Protocol
IKEv1 is specified by a series of RFCs, specifically RFCs 2401 through 2412. The most relevant are:
- RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP
- RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
- RFC 2409, The Internet Key Exchange (IKE)
- RFC 2412, Oakley Key Determination Protocol
IKEv1 combines features of the Internet Security Association and Key Management Protocol (ISAKMP) and Oakley Key Determination Protocol in order to negotiate Security Associations (SA) for two communicating peers. IKEv1 also provides for key agreement using Diffie-Hellman.
IKEv1 uses two phases. Phase 1 is used to establish an ISAKMP Security Association for IKEv1 itself. Phase 1 negotiates the authentication method and symmetric encryption algorithm to be used. Phase 1 requires either six messages (main mode) or three messages (aggressive mode).
Phase 2 negotiates the SA for two IPsec peers and is accomplished with three messages.
The initial IKEv1 implementation supports RFC 2409, Internet Key Exchange, and RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.
IKEv1 Configuration
IKEv1 configuration consists of five steps.
- Configure IKEv1 global parameters.
- Optionally, enable and configure Dead Peer Detection (DPD) Protocol.
- Configure IKEv1 interfaces.
- Configure IKEv1 Security Associations (SA).
- Assign the IKEv1 SA to an IPsec Security Policy.
IKEv1 Security Association Configuration
An IKEv1 SA identifies cryptographic material available for IPsec tunnel establishment.
To configure IKEv1 SA parameters:
- Use the
security-protocol
parameter to specify the IPsec security (authentication and encryption)
protocols supported by this SA.
The following security protocols are available.
Authentication Header (AH) — the default value — as defined by RFC 4302, IP Authentication Header, which provides authentication integrity to include the mutual identification of remote peers, non-repudiation of received traffic, detection of data that has been altered in transit, and detection of data that has been replayed, that is copied and then re-injected into the data stream at a later time. Authentication services utilize the authentication algorithm specified by the auth-algo property.
Encapsulating Security Payload (ESP) as defined by RFC 4303, IP Encapsulating Security Payload, which provides both authentication and privacy services. Privacy services utilize the encryption algorithm specified by the encryption-algo property.
ESP-AUTH (also RFC 4303-based), which supports ESP’s optional authentication.
ESP-NULL (also RFC 4303-based) which proves NULL encryption as described in RFC 2410, The NULL Encryption Algorithm and Its Use With IPsec. This option provides no privacy services, and is not recommended for production environments.
Refer to the following figures for additional details.
Figure 13-1 AH Transport Mode
Figure 13-2 AH Tunnel Mode
Figure 13-3 ESP Transport Mode
Figure 13-4 ESP Tunnel Mode
ORACLE(ike-sainfo)# security-protocol esp ORACLE(ike-sainfo)#
IKEv2 Protocol
IKEv2 is specified by a series of RFCs, specifically RFCs 2401 through 2412. The most relevant are:
- RFC 2412, Oakley Key Determination Protocol
- RFC 4301, Security Architecture for the Internet Protocol
- RFC 4306, Internet Key Exchange (IKEv2) Protocol
- RFC 4718, IKEv2 Clarifications and Implementation Guidelines
- RFC 5996, Internet Key Exchange (IKEv2) Protocol
IKEv2 combines features of the Internet Security Association and Key Management Protocol (ISAKMP) and Oakley Key Determination Protocol in order to negotiate Security Associations (SA) for two communicating peers. IKEv2 also provides for key agreement using Diffie-Hellman.
The initial IKEv2 implementation supports RFC 4306, Internet Key Exchange (IKEv2) Protocol, and RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.
IKEv2 Support
The Oracle® Enterprise Session Border Controller (ESBC) supports version 2 of the Internet Key Exchange (IKE) protocol. IKEv2 provides an initial handshake in which IKE peers negotiate cryptographic algorithms, mutually authenticate, and establish session keys to create an IKEv2 Security Association (SA) and an IPsec SA.
Key elements of IKEv2 support include:
- Peering/SIP Trunking solutions and access-side use cases
- Mutual authentication
between the
ESBC and its peers,
including:
- IKE rekey
- Dead Peer Detection (DPD)
- Initiator mode
- Responder mode
- Per-interface IKEv2 configuration
- Simultaneous support of IKEv1 and IKEv2 protocols
- Either tunnel or transport mode supported per IKE interface
- Transcoding
- Separate interfaces and IP addressing for SIP and IKE for related traffic
- Certificate-based authentication during IKEv2 tunnel establishment
- Multiple endpoints beyond tunnel remote address
With respect to IKE, if the peer does not support any of the encryption, hashing and integrity algorithms and Diffie Hellman groups supported by the ESBC, it rejects the IKEv2 establishment. With respect to IPsec, if the peer does not support any of the encryption, hashing and integrity algorithms supported by the ESBC, it does not create the child SA.
This can be implemented by removing these from the default list but allow manual configuration to add support.
At the IKEv2 global configuration level, users can do the following:
- Configure IKEv2 global parameters.
- Configure a default certificate profile.
- Configure pre-shared-keys if authentication is based on the contents of the IKEv2 Identification payload (optional).
Global configuration establishes a seet of default values. For overlapping configuration, the interface level takes precedence over global configuration.
Configuring IKEv2 Interfaces
After configuring global IKE parameters, use the procedures described in this chapter to configure and monitor IKEv2 interfaces.
IKEv2 interface configuration consists of the following steps.
- Configure IKE interface attributes
- Configure Security Associations
- Configure Security Policies
- Configure the Dead Peer Detection Protocol (optional)
- Configure the Online Certificate Status Protocol or Certificate Revocation List Support (optional)
- Configure Threshold Crossing Alerts (optional)
- Configure access control whit/black lists (optional)
Debugging IKEv2 IPsec Tunnel Establishment
The Oracle® Enterprise Session Border Controller provides details of all IKE endpoints that establish IKEv2/IPsec tunnels. Logging can also be enabled by IP address and userid.
In a typical deployment scenario, the IP address can be the public address of a NAT device that communicates with the Oracle® Enterprise Session Border Controller; the user-id can be the user-id of a femtocell or an IKE endpoint residing behind the NAT. The user-id can be an EAP identity exchanged during EAP authentication, or the identity contained in the IDi payload of the initial IKE_AUTH message. Typically the identity in the IDi payload is an IP address, an FQDN, or an address as defined in RFC 822, Standard for the Format of ARPA Internet Text Messages.
Enabling/Disabling Targeted Debugging
Targeted debugging is enabled by the security ike debug-logging peer-ip-userid ACLI command which takes a single string argument in the form ipAddress:userID. For example:
ORACLE# security ike debug-logging peer-ip-userid 172.16.20.1:12EDE12626719
ORACLE#With endpoint-specific logging enabled, the log.iked, log.authd, and log.secured files are populated with data pertinent to the target endpoint only and exclude date for all other endpoints. Logging is based on an exact match of the IP address and user-id provided by the argument string.
Note:
This command is expensive and should be used to debug one or two endpoints at a time. The operating system imposes a hard limit of no more than 5 simultaneous targeted debugging sessions.Use the no form of the command to stop an existing targeted debugging session
ORACLE# security ike debug-logging peer-ip-userid 172.16.20.1:12EDE12626719 no
ORACLE#Use the show security ike peer-endpoint-logging ACLI command to display a list of configured debug-logging sessions
ORACLE# show security ike peer-endpoint-logging
ORACLE#
IPaddress : Userid
==============
172.16.20.1:12EDE12626719
ORACLE#High Availability Caveat
Since the security ike debug-logging peer-ip-userid command is expensive, this implementation intentionally does NOT synchronize log data on the active and standby HA devices. Consequently, in the event of a switchover from the active to the standby, no log data is available on the newly active device. To enable debug-logging on the new active device, the user should verify tunnel establishment, and then use security ike debug-logging peer-ip-userid command on the currently active member of the HA pair.
Configure an IKEv2 Interface
This section covers IKEv2 global configuration parameters, omitting IKEv1 parameters. You can override global values set in the ike-config configuration element with values set at the ike-interface level.
IPsec Security Policy Configuration
You first define ike-sainfo elements that identify cryptographic material available for Security Association negotiation, and then define interface-specific IPsec Security Policies.
IPsec SA Configuration
During the IKE_AUTH exchange, cooperating peers use the secure channel previously established by the IKE_SA_INIT exchange to negotiate child IPsec SAs to construct secure end-to-end IPsec tunnels between the peers. IKE_SA_INIT negotiations use the values provided by the ike-sainfo configuration element.
Use the following procedure to create an ike-sainfo configuration element that specifies cryptographic material used for IPsec tunnel establishment. You will later assign this ike-sainfo configuration element to an IPsec Security Policy which defines IPsec services for a specified IKEv2 interface.
Enable Tunnel Pass-Through
Use IPsec Security Policies to enable tunnel pass-through.
Pass-through IPv4 traffic via an IPv4 tunnel
- Configure IPv4 allow policy for IKE protocol traffic
- Configure IPv4 ipsec policy for media traffic
- Configure the IKEv2 IPv4 interface with an IPv4 local address pool, or
- Configure the RADIUS server to return a Framed-IP-Address and/or Framed-IP-Netmask attribute
Pass-through IPv6 traffic via an IPv6 tunnel
- Configure IPv6 allow policy for IKE protocol traffic
- Configure IPv6 ipsec policy for media traffic
- Configure the IKEv2 IPv6 interface with an IPv6local address pool, or
- Configure the RADIUS server to return a Framed-IPv6-Prefix or Framed-IPv6-Pool attribute
Pass-through IPv4 traffic via an IPv6 tunnel
- Configure IPv6 allow policy for IKE protocol traffic
- Configure IPv4 ipsec policy for media traffic
- Configure the IKEv2 IPv6 interface with an IPv4 local address pool, or
- Configure the RADIUS server to return a Framed-IP Address and/or Framed-IP-Netmask attribute
Pass-through IPv6 traffic via an IPv4 tunnel
- Configure IPv4 allow policy for IKE protocol traffic
- Configure IPv6 ipsec policy for media traffic
- Configure the IKEv2 IPv4 interface with an IPv6local address pool, or
- Configure the RADIUS server to return a Framed-IPv6-Prefix or Framed-IPv6-Pool attribute
IPSec SA Rekey on Sequence Number Overflow
The Oracle® Enterprise Session Border Controller establishes a new IPSec security association (SA) when the counter for the outbound 32-bit Sequence Number (SN) or the 64-bit Extended Sequence Number (ESN) overflows.
The SN or ESN counter is incremented for every outbound packet. These counters can overflow when the ESBC is handling packet intensive services such as video streaming or long duration calls. In accordance with RFCs 4303 and 7296, the ESBC establishes new security associations, as part of rekeying, before the SN or ESN counters can roll over. It does this through the use of two parameters in the ipsec-global-config configuration element: rekey-on-sn-overflow, the default for which is enabled, and sn-rekey-threshold, which identifies the threshold for rekeying security associations as a percentage of the counter capacity and for which the default is 95.
There are four ACLI commands you can use to monitor SN and ESN counter overflows:
show datapath etc-stats ppms ipsec
- ob-sn-threshold-overflows — This counter is incremented when the SN for an outbound SA for a tunnel exceeds the user-configured threshold value.
- ob-sn-32bit-overflows — This counter is incremented when the lower 32-bits of the outbound ESN (when ESN is enabled) overflows.
- standby-ob-sn-overflows — This counter is incremented when the SN or ESN for an outbound SA for a tunnel overflows the threshold value installed on the standby node during SA installation or update on the standby system.
- ib-sn-32bit-overflows — This counter is incremented when the lower 32 bits of the inbound ESN (when ESN is enabled) overflows.
show datapath netlink show
Issuing this command shows the total number of SN overflow notifications received by the netlink layer on the host processor. The four newly-added parameters are the same as those in show datapath etc-stats ppms ipsec.
show sa stats ike
Issuing this command shows the number of times an SN overflow triggered a request for an IPsec rekey to acquire a new SA, as well as the number of times rekey requests succeeded and failed.
show security ike statistics
Issuing this command shows, with the parameter RekeyOnSNoverflow the number of times an SN overflow triggered an IPsec rekey.
Pre-Populated ARP Table
In certain topologies remote IPsec endpoints can require access to core network hosts reachable through a Oracle® Enterprise Session Border Controller core interface. In these instances, the ESBC receives the tunneled packet, and masks the received IP destination address against its own local addresses to determines if direct delivery is possible. If so, the ESBC issues an ARP request to obtain the physical destination address.
This process can be expedited by pre-populating the interface-specific ARP table with a list of commonly accessed core network host reachable by that interface. With the ARP table pre-populated with IP addresses, the ARP process issues ARP requests at 5 second intervals until a response is received. Once the pre-populated IP address has been resolved, periodic ARP refreshes are used to maintain the currency of the resolution.
Configure Dead Peer Detection
Dead Peer Detection is enabled by setting the dpd-time-interval parameter to a non-zero value. DPD exchanges are asynchronous, consisting of a simple R-U-THERE and an ACK.
Certificate Revocation Lists
A Certificate Revocation List (CRL) contains a list of the serial numbers of certificates that have been revoked by the issuing Certification Authority (CA). Such issuing authorities update CRLs periodically, and make the updates lists available to subscribers. CRL updates can be deliver in either PEM (Privacy Enhanced Email) or DER (Distinguished Encoding Rules) format. PEM is base-64 encoded ASCII that provides BEGIN CERTIFICATE and END CERTIFICATE statements; DIR is a binary rendering of the PEM format. Both formats (PEM and DIR) are supported by the Oracle® Enterprise Session Border Controller.
When authentication of remote IKEv2 peers is certificate-based, you can enable CRL usage on IKEv2 interfaces to verify certificate status.
CRL-Based Certificate Verification
This section provides instruction on using the ACLI to configure periodic retrieval of CRLs.
Configuration of CRL-based certificate verification is a three-step process.
- Specify the information and cryptological resources required to access one or more CRL sources.
- If not already done, enable CRL usage on an IKEv2 interface.
- Associate one or more CRLs with an IKEv2 interface.
Configure CRL Certificate Verification
The cert-status-profile element is a container for the information required to access a specific CRL source.
SNMP Traps
An SNMP trap is thrown, and a major alarm generated, if the Oracle® Enterprise Session Border Controller is unable to retrieve a CRL from the server. This trap includes the server’s FQDN, assuming that the FQDN has been identified during the configuration process, the server’s IP address, the reason for the failure, and the time of the last successful CRL retrieval, with the time expressed as the number of seconds since midnight January 1, 1970.
A second SNMP trap is thrown when the ESBC successfully retrieves a CRL. This trap includes the server’s FQDN, assuming that the FQDN has been identified during the configuration process, and the server’s IP address. The issue of this trap also clears any associated major alarm.
Configuring Manual CRL Updates
The ACLI provides the ability to perform an immediate manual refresh of one or more CRLs.
Use the following command to refresh a single CRL.
ORACLE# load-crl local-file <fileName>where <fileName> is a remote filepath specified by the crl-list attribute.
Use the following command to refresh all CRLs.
ORACLE# load-crl local-file allUse 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 allOnline Certificate Status Protocol
The Online Certificate Status Protocol (OCSP) enables users to determine the revocation state of a specific certificate. Because OCSP ensures access to the freshest CRL, it can provide a more timely source of revocation information than is possible with dynamically or manually loaded CRLs. Guaranteed access to the most recent CRL, however, comes at the expense of increased traffic: a single request/response exchange for each revocation check.
If the OCSP responder returns a status of good, the certificate is accepted and authentication succeeds. If the OCSP responder returns a status other than good, the certificate is rejected and authentication fails.
Certificate status is reported as
- good—which indicates a positive response to the status inquiry. At a minimum, a positive response indicates that the certificate is not revoked, but does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate’s validity interval.
- revoked—which indicates a negative response to the status inquiry. The certificate has been revoked, either permanently or temporarily.
- unknown—which indicates a negative response to the status inquiry. The responder cannot identify the certificate.
When authentication of remote IKEv2 peers is certificate-based, you can enable OCSP on IKEv2 interfaces to verify certificate status.
OCSP-Based Certificate Verification
The following sections provides instruction on using the ACLI to configure OCSP-based certificate verification.
Configuration of OCSP-based certificate verification is a three-step process.
- Specify the information and cryptological resources required to access one or more OSCP responders.
- Enable OCSP on an IKEv2 interface.
- Associate one or more OCSP responders with an IKEv2 interface.
Threat Protection
IKEv2 threat protection is composed of:
- IP-header based firewalls
Stateless Firewall
The ESBC provides enhanced security-policy-based filters that can be applied to data packets coming through IPSec tunnels on the protected interfaces, and to non-IPSec packets on the trusted interfaces. These filters evaluate only the IP header layer, and treat each individual packet as a discrete event. As such, the functionality they provide can be compared to that provided by a stateless firewall.
Available filters are discussed in the following sections.
ICMP Filtering
Internet Control Message Protocol (ICMP) messages can be filtered based on message Type and associated message Codes.
ICMP Policy Configuration
Use the following procedure to define security-policy-based filtering of ICMP packets. This sample policy discards ICMP message type 0, Echo Reply, code 0, Net Unreachable.
SCTP Filters
Internet Control Message Protocol (ICMP) messages can be filtered based on Payload Protocol Identifiers.
SCTP Policy Configuration
Use the following procedure to define security-policy-based filtering of SCTP packets. This sample policy allows SCTP, Payload Protocol Identifier 34, Diameter in SCTP DATA chunk.
Source Routing Packets
The ESBC can unconditionally discard all source routed packets at the global level. Source routed packets are identified by the presence of either a Loose Source Route/Record (LSRR) or a Strict Source Route/Record (SSRR) option within the IP header Options header.
Both options have the potential to mask malicious intent. An attacker can use the specified routes to hide the true source of a packet, or to gain access to a protected network. Consequently, such packets are often dropped upon network entry.
Use the following procedure to unconditionally discard all source routed packets.
Fragmented Packets
The ESBC can unconditionally discard all inbound fragmented Encapsulating Security Protocol (ESP) packets using a global option. Refer to Figure 3, ESP Transport Mode, and Figure 5, ESP Tunnel Mode, for ESP details.
Upon reception, the SG re-assembles such packets and then decrypts the re-assembled packet. After decryption, if the decrypted packet is still a fragment, the new option mandates that the packet fragment be discarded in light of the SG’s inability to do a proper policy check on an incomplete message.
Use the following procedure to unconditionally discard all fragmented ESP packets.
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-minor0t=time
t=0 ike-dpd counter= 30 ike-dpd alert level=clear
t=1 ike-dpd counter= 60 ike-dpd alert level=clear
t=2 ike-dpd counter= 80 ike-dpd alert level=major trap sent
t=3 ike-dpd counter= 95 ike-dpd alert level=major
t=4 ike-dpd counter=100 ike-dpd alert level=critical trap sent
t=5 ike-dpd counter=120 ike-dpd alert level=critical
t=6 ike-dpd counter= 99 ike-dpd alert level=critical
t=7 ike-dpd counter= 90 ike-dpd alert level=major trap sent
t=8 ike-dpd counter= 60 ike-dpd alert level=major
t=9 ike-dpd counter= 0 ike-dpd alert level=clear trap sent
Use the following procedure to configure TCAs.
IKEv2 Interface Management
The following two sections provide details on available counters that gather usage and error data related to IKEv2/IPsec operations on the Oracle® Enterprise Session Border Controller.
The first section, IKEv2 Protocol Operations, describes a series of 32-bit counters that report interface-specific data on various protocol transactions. Protocol operations counter values are available with SNMP, through the ACLI show security ike statistics command, and can also be obtained by subscription to the ike_stats HDR group.
The second section, IKEv2 Negotiation Errors, describes a series of 32-bit counters that report interface-specific errors encountered during IKEv2 negotiations. Negotiation errors counter values are also available with SNMP, through the ACLI show security ike statistics command, and can also be obtained by subscription to the ike-stats HDR group.
The third section, RADIUS Protocol Operations, describes a series of 32-bit counters that report RADIUS-server-specific data. RADIUS protocol operations counter values are also available with SNMP, through the ACLI show radius command, and can also be obtained by subscription to the radius-stats HDR group.
The final section, Diameter Protocol Operations, describes a series of 32-bit counters that report Diameter-server-specific data. Diameter protocol operations counter values are also available with SNMP, and can also be obtained by subscription to the diameter-stats HDR group.
IKEv2 Protocol Operations
Note:
The range for all 32-bit counters is 0 to 4294967295.| Name | Description | Type | SNMP MIB Ending |
|---|---|---|---|
| Current Child SA Pairs | The number of current child IPsec SA pairs on the interface. As each IPsec tunnel requires two unidirectional SAs, this number equals the current number of tunnels on the interface. Note that this count is available through both an ACLI show command and an SNMP GET operation. | gauge | .33 |
| Maximum Child SA Pairs | The largest number of child IPsec SA pairs on the interface since this counter was last reset. As each IPsec tunnel requires a single SA pair, this value equates to the largest number of tunnels on the interface. | gauge | |
| Last Reset Timestamp | The time that this interface was last reset -- expressed as a UNIX timestamp containing the number of seconds since January 1, 1970. | UNIX timestamp | |
| Child SA Request | The number of requests to add a child SA pair that were received on the interface. These requests include IPsec SA rekey requests. | counter | .1 |
| Child SA Success | The number of requests to add a child SA pair that were successfully completed on the interface. These successes include new children created by IPsec SA rekeys. | counter | .2 |
| Child SA Failure | The number of requests to add a child SA pair that were not successfully completed on the interface. These failures include unsuccessful IPsec SA rekeys. | counter | .3 |
| Child SA Delete Requests | The number of requests to delete a child SA pair that were received on the interface. These requests include deletion requests associated with IPsec SA rekeys. | counter | .4 |
| Child SA Delete Success | The number of requests to delete a child SA pair that were successfully completed on the interface. These successes include children deleted by IPsec SA rekeys. | counter | .5 |
| Child SA Delete Failure | The number of requests to delete a child SA pair that were not successfully completed on the interface. These failures include unsuccessful deletions associated IPsec SA rekeys. | counter | .6 |
| Child SA Rekey | The number of child IPsec rekey exchanges transacted on the interface. | counter | .7 |
| Initial Child SA Establishment | The number of initial child SA pair establishments, in other words, the number of successful IKE_AUTH exchanges transacted on the interface. | counter | .8 |
| DPD Received Port Change | The number of DPD messages received on the interface that contained a port change from the previously received message. The port change indicates that the IKEv2 has moved to another port, or that an intervening NAT device has changed port mapping. These actions do not impact SA functions. | counter | .9 |
| DPD Received IP Change | The number of DPD messages received on the interface that contained an IP address change from the previously received message. | counter | .10 |
| DPD Response Received | The number of DPD ACK responses received on the interface. An ACK is sent by an IKEv2 peer in response to an R-U-THERE issued by the Oracle® Enterprise Session Border Controller. A successful R-U-THERE/ACK exchange establishes availability on the remote IKEv2 peer. | counter | .11 |
| DPD Response Not Received | The number of R-U-THERE messages transmitted on the interface that were not acknowledged within the DPD allowed interval. | counter | .12 |
| DPD Received | The number of all DPD protocol messages received on the interface. | counter | .13 |
| DPD Retransmitted | The number of R-U-THERE messages that were re-transmitted because the original R-U-THERE message was not acknowledged. | counter | .14 |
| DPD Sent | The number of R-U-THERE messages that were sent across the interface, to include retransmitals. | counter | .15 |
| IKE SA Packets Sent | The number of IKEv2 SA packets sent across the interface. | counter | .16 |
| IKE SA Packets Received | The number of IKEv2 SA packets received across the interface. | counter | .17 |
| IKE SA Packets Dropped | The number of IKEv2 SA packets dropped by the interface. | counter | .18 |
| Authentication Failures | The number of authentication failures that occurred after the purported identity of the remote IKEv2 peer was ascertained. | counter | .19 |
| IKE Message Errors | The number of otherwise uncharacterized IKEv2 message errors. | counter | .20 |
| Authentication ID Errors | The number of errors that occurred during the identification stage of the authentication process. | counter | .21 |
| Certificate Status Requests | The number of certificate status requests sent across the interface to an OCSP responder. | counter | .22 |
| Certificate Status Success | The total number of OCSP successes, that is the number of OCSP requests that generated a good status from an OCSP responder. | counter | .23 |
| Certificate Status Fail | The total number of OCSP failures, to include unacknowledged OCSP requests and those requests that generated a revoked or unknown response from an OCSP responder. | counter | .24 |
| DDoS Sent | The number of suspicious, and possibly malicious, endpoints reported by the interface-specific DDoS process (if configured as described in the IKEv2 DDoS Protection section of the Oracle® Enterprise Session Border Controller Essentials guide). | counter | .25 |
| DDoS Received | The number of suspicious, and possibly malicious, endpoints reported by statically provisioned deny lists (as described in SIP Signaling Services and Security chapters of the ACLI Configuration Guide). | counter | .26 |
| IKE Message Retransmissions | The total number of IKEv2 message re-transmissions. | counter | .27 |
| SA Init Messages Received | The total number of IKEv2 message re-transmissions. | counter | .28 |
| SA Init Message Sent | The total number of IKEv2 message re-transmissions. | counter | .29 |
| SA Establishment Attempts | The total number of IKEv2 message re-transmissions. | counter | .30 |
| SA Establishment Success | The total number of IKEv2 SA successfully established on the IKEv2 interface. | counter | .31 |
| Tunnel Rate | Specifies the tunnel establishment rate, in terms of tunnels created per second. Note that this count is available through both an ACLI show command and an SNMP GET operation. | gauge | .32 |
IKEv2 Negotiation Errors
The SNMP MIB is formed by appending the value in the SNMP MIB Ending column to 1.3.6.1.4.1.9148.3.9.1.3.X (apSecurityIkeInterfaceStatsEntry), where X specifies the interface index. For example, the SNMP MIB for the CPU Overload Errors is 1.3.6.1.4.1.9148.3.9.1.3.X.3, where X specifies the interface index.
| Name | Description | SNMP MIB Ending |
|---|---|---|
| CPU Overload Errors | The number of IKEv2 requests that were rejected because of CPU load constraints. | .3 |
| Init Cookie Errors | The number of all IKEv2 exchanges that failed because of faulty Security Parameter Index (SPI) values. SPIs provide a local SA identifier and are exchanged between IKEv2 peers in the common IKEv2 header and in Notify Payloads. | .4 |
| Auth Errors | The number of failed IKE_AUTH exchanges, regardless of the specific reason for failure. | .5 |
| EAP Access Request Errors | The number of authentication failures that occur ed during the EAP access phase. | .6 |
| EAP Access Challenge Errors | The number of authentication failures that occur ed during the EAP challenge phase. | .7 |
| TS Errors | The number of CREATE_CHILD_SA exchanges that failed because of faulty TS payload contents, or failure on the part of the remote peers to negotiate the offered traffic selectors. | .8 |
| CP Errors | The number of IKE_AUTH and/or CREATE_CHILD_SA exchanges that failed because of faulty, unsupported, or unknown Configuration Payload contents. | .9 |
| IKE Errors | The number of IKE_SA_INIT and/or CREATE_CHILD_SA exchanges that failed because of faulty, unsupported, or unknown Key Exchange Payload contents. | .10 |
| Proposal Errors | The number of failed negotiations that resulted from the inability to reconcile crytographic proposals contained in the Security Association Payloads exchanged by IKEv2 peers. Security Association Payloads are exchanged during the IKE_SA_INIT, IKE_AUTH, and CREATE_CHILD_SA stages. | .11 |
| Syntax Errors | The number of failed negotiations, of any type, resulting from otherwise uncharacterized errors. | .12 |
| Critical Payload Errors | The number of failed negotiations that resulted from the presence of a Critical flag in a payload that could not be parsed, or was not supported. IKEv2 adds a critical flag to each payload header for further flexibility for forward compatibility. If the critical flag is set and the payload type is unrecognized, the message must be rejected and the response to the IKE request containing that payload MUST include a Notify payload UNSUPPORTED_CRITICAL_PAYLOAD, indicating an unsupported critical payload was included. If the critical flag is not set and the payload type is unsupported, that payload must be ignored. | .13 |
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.15with a specified interface, displays performance and error counters for the target interface
ORACLE# show security allwith 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.15with a specified interface, resets performance and error counters for the target interface
ORACLE# reset ike-stats allwith 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-mibre-sets the MIB-based error counters for all IKEv2 interfaces
IKEv2 and Child SAs
Use the show security command with optional arguments to display IKEv2 and child SA information to include:
- IP address and port of remote end-point
- intervening NAT device (yes | no)
- local IP address
- tunnel state (up | down)
- initiator cookie
- responder cookie
- remote inner (tunnel) IP address
- incoming/outgoing Security Parameter Indexes (SPI) of the child SA
ORACLE# show security sad ike-interface 192.169.204.15with a specified interface address, displays SA information for a single IKEv2 interface
ORACLE# show security sad ike-interface allwith all, displays SA information for all IKEv2 interfaces
ORACLE# show security sad ike-interface all
Displaying the total (4321) number of entries may take long and could affect system performance.
Continue? [y/n]?: y
Peer: 6.0.0.36:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x23e71b73d5a10c58[I] 0xd2017a6fb84a4fa6[R]
Child Peer IP: 101.0.0.36:0 Child SPI: 4236760138[I] 1721373661[O]
Peer: 6.0.0.28:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0xf64d031d32525730[I] 0xcea2d5ae3c91050f[R]
Child Peer IP: 101.0.0.28:0 Child SPI: 3632387333[I] 1421117246[O]
Peer: 6.0.0.9:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x84ec95a1cd0a4c5d[I] 0x1b61b385c4e627b4[R]
Child Peer IP: 101.0.0.9:0 Child SPI: 2432742837[I] 3872387177[O]
Peer: 6.0.0.25:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x541b2651e88c9368[I] 0xdc393a61af6dc909[R]
Child Peer IP: 101.0.0.25:0 Child SPI: 785656546[I] 148357787[O]
Peer: 6.0.0.27:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x3ba43c5c685e37e6[I] 0x7bfa6f0781dce1a8[R]
Child Peer IP: 101.0.0.27:0 Child SPI: 767765646[I] 3797275291[O]
Peer: 6.0.0.22:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x925e540ecbd58dbb[I] 0x7e1101371a5a5823[R]
Child Peer IP: 101.0.0.22:0 Child SPI: 787745714[I] 876969665[O]
Peer: 6.0.0.2:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0xda0f568684ba5e2c[I] 0x74c533da2fd29901[R]
Child Peer IP: 101.0.0.2:0 Child SPI: 3884481109[I] 1862217459[O]
Peer: 6.0.0.7:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x6166bac4438f3ca7[I] 0x71d1049a0f8520f4[R]
Child Peer IP: 101.0.0.7:0 Child SPI: 2798332266[I] 2789214337[O]
Peer: 6.0.0.15:500 (NAT: No) Host: 172.16.101.2 State: Up
IKE Cookies: 0x0e060701115069bf[I] 0x2e69adbf15438000[R]
Child Peer IP: 101.0.0.15:0 Child SPI: 713005957[I] 1985608540[O]
Continue? [y/n]?: y
...
...Use show security with the peer address obtained by the previous command to display more detailed information regarding a specific tunnel to include:
- IKE version
- Diffie Hellman group
- the IKE SA hash algorithm
- the IKE SA message authentication code algorithm
- the IKE SA encryption algorithm
- seconds since SA creation
- SA lifetime in seconds
- remaining lifetime in seconds
- IPsec operational mode (tunnel | transport)
- IPsec security protocol (AH |ESP)
- IPsec authentication protocol (SHA1 | MD5 | any)
- IPsec encryption protocol (AES | 3DES | null| any)
ORACLE# show security sad ike-interface <ipAddress> peer <ipAddress>
ORACLE# show security sad ike-interface 172.16.101.2 peer 6.0.0.36:500
IKE SA:
IKE Version : 2
Tunnel State : Up
Last Response [Seconds] : 212
AAA Identity :
NAT : No
IP Addresses [IP:Port]
Peer : 6.0.0.36:500
Server Instance : 172.16.101.2:500
Cookies
Initiator : 0x23e71b73d5a10c58
Responder : 0xd2017a6fb84a4fa6
Algorithms
DH Group : 2
Hash : HMAC-SHA1
MAC : SHA1-96
Cipher : 3DES
SA Times [Seconds]
Creation : 141
Expiry : 86400
Remaining : 86188
IPSec SA:
IP Addresses [IP:Port]
Destination : 101.0.0.36:0
Source : 172.16.101.2:0
SPI
Outbound : 1721373661
Inbound : 4236760138
Algorithms
Mode : TUNNEL
Protocol : ESP
Authentication : SHA1
Encryption : AES
Traffic Selectors [Start IP - End IP]
Destination : 101.0.0.36 - 101.0.0.36
Source : 172.16.101.2 - 172.16.101.2TCA Counters
An ACLI command is provided to display TCA information.
ORACLE# show security ike threshold-crossing-alert <ipAddress> || allwith 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: clearHistorical 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 |
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 |