Communications Monitor Configuration

Operations Monitor Configuration

The Operations Monitor configuration process includes the following steps.

Configure of one or more Oracle Communications Session Border Controller-Operations Monitor exporter-collector pairs.
Optional—Assign a TLS profile to an exporter-collector pair.

Configure the Operations Monitor

Use the following procedure to configure the Operations Monitor.

From superuser mode, use the following ACLI sequence to access comm-monitor configuration mode. From comm-monitor mode, you establish a connection between the Oracle Communications Session Border Controller (SBC), acting as a exporter of protocol message traffic and related data, and an Operations Monitor Mediation Engine, acting as an information collector.
```
ACMEPACKET# configure terminal
ACMEPACKET(configure)# system
ACMEPACKET(system)# system-config
ACMEPACKET(system-config)# comm-monitor
ACMEPACKET(comm-monitor)#
```
Use the state parameter to enable or disable communication monitoring.
Communication monitoring is disabled by default.
```
ACMEPACKET(comm-monitor)# state enabled
ACMEPACKET(comm-monitor)#
```
Use the sbc-group-id parameter to assign an integer value to the SBC, in its role as an information exporter.
Retain the default value (0) or assign another integer value.
```
ACMEPACKET(comm-monitor)# sbc-group-id 5
ACMEPACKET(comm-monitor)#
```
Optional—If the network interface specified in Step 8 is a media interface, you can use TLS to encrypt the exporter-collector connection.
To enable TLS encryption, use the tls-profile parameter to identify a TLS profile to be assigned to the network interface. The absence of an assigned TLS profile (the default state) results in unencrypted transmission.

Refer to TLS Profile Configuration for configuration details.
```
ACMEPACKET(comm-monitor)# tls-profile commMonitor
ACMEPACKET(comm-monitor)#
```
Use the qos-enable parameter to enable or disable to export of RTP, SRTP, and QoS data flow information.
```
ACMEPACKET(comm-monitor)# qos-enable enabled
ACMEPACKET(comm-monitor)#
```
Use the interim-qos-update parameter to enable or disable 10 second interim QoS update.
```
ACMEPACKET(comm-monitor)# interim-qos-enable enabled
ACMEPACKET(comm-monitor)#
```
Use the monitor-collector parameter to move to monitor-collector configuration mode.
While in this mode you identify an Operations Monitor Mediation Engine collector by IP address and port number.
```
ACMEPACKET(comm-monitor)# monitor-collector
ACMEPACKET(monitor-collector)#
```
Use the address and port parameters to specify the IP address and port number monitored by an Operations Monitor Mediation Engine for incoming IPFIX traffic.
Enter an IPv4 address and a port number with values either 4739 (unsecured) or 4740 (secured). The default value for the port is 4739.
```
ACMEPACKET(monitor-collector)# address 172.30.101.239
ACMEPACKET(monitor-collector)# port 4739
ACMEPACKET(monitor-collector)#
```
Use the network-interface parameter to specify the network interface that supports the TCP connection between the SBC to the Operations Monitor Mediation Engine.
To specify the wancom0 management interface:
```
ACMEPACKET(comm-monitor)# network-interface wancom0:0
ACMEPACKET(comm-monitor)#
```
To specify a media interface:
```
ACMEPACKET(comm-monitor)# network-interface m01
ACMEPACKET(comm-monitor)#
```
Note:
If configuring with a media interface, that interface must belong to a configured realm.
Use done and exit to return to comm-monitor configuration mode.
Use done, exit, and verify-config to complete configuration.
Repeat Steps 1 through 10 to configure additional as required.

TSCF Rekey Profile Configuration

Rekeying is a cryptographic technique that enhances security by enforcing the negotiation of existing keys on an ongoing secure connection. Rekeying can be either time-based, in which case new keys are negotiated at the expiration of a timer, or traffic-based, in which case new keys are negotiated when a threshold byte count is exceeded.

Use the following procedure to configure an optional tscf-rekey-profile. Later, you will assign the profile to a specific TSCF interface. If you do not intend to enforce re-keying, this procedure can be safely ignored.

From superuser mode, use the following command sequence to access tscf-rekey-profile configuration mode.

ACMEPACKET# configure terminal
ACMEPACKET(configure)# security
ACMEPACKET(security)# tscf
ACMEPACKET(tscf)# tscf-rekey-profile
ACMEPACKET(tscf-rekey-profile)#

Use the name parameter to provide a unique identifier for this tscf-rekey-profile.

ACMEPACKET(tscf-rekey-profile)# name tscfRekey01
ACMEPACKET(tscf-rekey-profile)#

Use the initiator parameter to identify the rekey initiator.
Supported values are client (default) | server (the SBC)
```
ACMEPACKET(tscf-rekey-profile)# initiator client
ACMEPACKET(tscf-rekey-profile)#
```
Use the max-rekey-time parameter to specify the maximum interval (in minutes) between re-keying operations.
Supported values are 0 (default) | 30 - 1440 (minutes)

The default value, 0, specifies that time-based rekeying is not enforced; other integer values specify that time-based re-keying must be initiated by the tunnel endpoint designated by the initiator parameter.
```
ACMEPACKET(tscf-rekey-profile)# max-rekey-time 30
ACMEPACKET(tscf-rekey-profile)#
```
Use the max-rekey-data parameter to specify the maximum traffic exchange (measured in Kb) between rekeying operations.
The default value, 0, specifies that traffic-based rekeying is not enforced; other integer values specify that traffic-based re-keying must be initiated by the tunnel endpoint designated by the initiator parameter.
```
ACMEPACKET(tscf-rekey-profile)# max-rekey-data 0
ACMEPACKET(tscf-rekey-profile)#
```
Use done, exit, and verify-config to complete tscf-rekey-profile configuration.
Repeat Steps 1 through 6 to configure additional tscf-rekey-profiles as required.

Configure TLS Profile

Use the following procedure to configure a tls-profile that identifies the cryptographic resources, specifically certificates and protocols, required for the establishment of a secure/encrypted connection between the Oracle Communications Session Border Controller and the Operations Monitor (OM) Mediation Engine.

From superuser mode, use the following command sequence to access tls-profile configuration mode.

ACMEPACKET# configure terminal
ACMEPACKET(configure)# security
ACMEPACKET(security)# tls-profile
ACMEPACKET(tls-profile)#

Use the name parameter to provide a unique identifier for this tls-profile.
```
ACMEPACKET(tls-profile)# name commMonitor
ACMEPACKET(tls-profile)#
```
Use the required end-entity-certificate parameter to specify the name of the certificate-record configuration that identifies the credential (specifically, an X509.v3 certificate) offered by the Oracle Communications Session Border Controller in support of its asserted identity.
```
ACMEPACKET(tls-profile)# end-entity-certificate commMonitor509
ACMEPACKET(tls-profile)#
```
Use the required trusted-ca-certificates parameter to compile a list or one or more certificate-record configuration elements referencing trusted Certification Authority (CA) certificates used to authenticate the offered certificate. These referenced certificates are conveyed to the OM Monitor Mediation Engine as part of the TLS exchange.
Provide a comma separated list of existing CA certificate-record configuration elements.
```
ACMEPACKET(tls-profile)# trusted-ca-certificates verisignClass3-a,verisignClass3-b,baltimore,thawtePremium,acme-CA
ACMEPACKET(tls-profile)#
```
Retain the default value, all, for the cipher-list parameter.
Use the verify-depth parameter to specify the maximum number of chained certificates that will be processed while authenticating end-entity certificate received from the OM Mediation Engine.
Provide an integer within the range 1 through 10 (the default).

The Oracle Communications Session Border Controller supports the processing of certificate chains (consisting of an end-entity certificate and some number of CA certificates) when X.509v3 certificate-based authentication is used. The following process validates a received TLS certificate chain.
- Check the validity dates (Not Before and Not After fields) of the end certificate. If either date is invalid, authentication fails; otherwise, continue chain validation
- Check the maximum length of the certificate chain (specified by verify-depth). If the current chain exceeds this value, authentication fails; otherwise, continue chain validation.
- Verify that the Issuer field of the current certificate is identical to the Subject field of the next certificate in the chain. If values are not identical, authentication fails; otherwise, continue chain validation.
- Check the validity dates (Not Before and Not After fields) of the next certificate. If either date is invalid, authentication fails; otherwise, continue chain validation.
- Check the X509v3 Extensions field to verify that the current certificate identifies a CA. If not so, authentication fails; otherwise, continue chain validation.
- Extract the Public Key from the current CA certificate. Use it to decode the Signature field of the prior certificate in the chain. The decoded Signature field yields an MD5 hash value for the contents of that certificate (minus the Signature field).
- Compute the same MD5 hash. If the results are not identical, authentication fails; otherwise, continue chain validation.
- If the hashes are identical, determine if the CA identified by the current certificate is a trust anchor by referring to the trusted-ca-certificates attribute of the associated TLS-profile configuration object. If the CA is trusted, authentication succeeds. If not, return to Step 2.
```
ACMEPACKET(tls-profile)# verify-depth 8
ACMEPACKET(tls-profile)#
```
Use the mutual-authenticate parameter to enable or disable (the default) mutual authentication.
Protocol requirements mandate that the server present its certificate to the client application. Optionally, the server can implement mutual authentication by requesting a certificate from the client application, and authenticating the certificate offered by the client.

Upon receiving a server certificate request, the client application must respond with a certificate; failure to do so results in authentication failure.
```
ACMEPACKET(tls-profile)# mutual-authenticate disabled
ACMEPACKET(tls-profile)#
```
Set tls-version to compatibility.
Retain default values for all other parameters.
Use done, exit, and verify-config to complete tls-profile configuration.
Repeat Steps 1 through 10 to configure additional tls-profiles as required.

Anonymize Personal Data in Messaging Sent to the Operations Monitor

When you allow people to examine SIP INVITE or SIP MESSAGE messages in the Operations Monitor (OM), you might want to hide certain sensitive information from their view for security and confidentiality reasons. For example, you might want to hide the SUBJECT header in the message and in the CPIM body, as well as the MIME content of the CPIM body. Oracle's solution is to provide an option to anonymize such information for display in the OM.

When you enable the anonymize-invite option, the system makes a copy of the inbound SIP INVITE and allows the original to continue on its way. In the copy, the system parses the body of the INVITE and replaces the SUBJECT header and MIME content with a hyphen (-). No other message content is affected, and the full functionality of the OM remains available. When the troubleshooter views the SIP INVITE message, OM displays the anonymized copy of the SIP INVITE.

You can also enable the anonymize-message option, which performs the same functions to the SIP MESSAGE, defined in RFC 3428, to support the transfer of Instant Messages. When enabled, this option hides the SUBJECT header as well as the CPIM subject and MIME content, replacing them with a hyphen (-) before sending them to OM.

The default setting for both options is disabled. Use the options parameter in the comm-monitor configuration to enable them.

Enable Anonymization of Information Sent to OM

When you want to hide certain sensitive information in a SIP INVITE message that the Operations Monitor (OM) can display, you can configure the Oracle Communications Session Border Controller (SBC) to anonymize the SUBJECT header in the message and in the CPIM body, as well as the MIME content of the CPIM body with the anonymize-invite option.

Note:

The anonymize-invite option for CommMonitor is not RTC.

You can enable the same functionality for the SIP MESSAGE method using the anonymize-message option. You can enable both options on the same comm-monitor, if desired using the options' plus-sign (+) syntax.

The default setting for these anonymize options is disabled. Use the options parameter in the comm-monitor configuration to enable them.

Access the comm-monitor configuration element.

ORACLE# configure terminal
ORACLE(configure)# system
ORACLE(system)# system-config
ORACLE(system-config)# comm-monitor
ORACLE(comm-monitor)#

Select the comm-monitor instance that you want to enable for anonymization.
Set the anonymize-invite option, referring to the syntax below, and press ENTER.
```
ORACLE(comm-monitor)#options + anonymize-invite
```
To perform the same functionality on the SIP MESSAGE method, use the same syntax as above replacing the option with anonymize-message, and press ENTER.
Save and exit the configuration.