TSCF Server Configuration

TSC server configuration consists of the following steps; each step is identified as required or optional.

Configure TSCF global behavior (optional)

Configuration of the tscf-config object specifies the handling of idle tunnel connections. Default values can be retained to enable standard tunnel processing.
Configure TSCF OCSP policy-based forwarding services (optional)

The TSCF protocol policy configuration enables the forwarding of both tunneled and detunneled traffic depending on certain parameters in the packet headers. When packets are to be forwarded from one realm to another, or to a specific destination IP address as they are passing through the TSC server, create TSCF OCSP Protocol Policies. Packets may also be directed to a LDAP server for user authentication, or detunneled traffic may be sent to an XMPP server.
Configure one or more TSCF address pools (required)

A tscf-address-pool specifies one or more contiguous ranges of IP addresses that are available for assignment to client applications. Later in the configuration process, you will assign an existing address pool to a TSCF interface. If the tscf-address-pool is used in conjunction with an optional tscf-data-flow, the combination provides a static egress route for tunneled traffic.
Configure one or more TSCF data flows (optional)

This configuration while optional is almost always performed A tscf-data-flow operates in conjunction with a tscf-address-pool to provide a static egress route for tunneled traffic, usually to a gateway or application server.
Configure TLS or DTLS profiles (required for production environments)

This configuration encrypts tunneled traffic using either TLS to encrypt streamed TCP packets or DTLS to encrypt UDP datagrams. In test/debug environments it can be advantageous to disable encryption. A tls-profile identifies the cryptographic resources available to ensure privacy using TLS or DTLS.
Configure one or more TSCF interfaces and ports (required)

A tscf-interface and its associated tscf-ports provide server-side tunnel connectivity,
Enable DoS protection on TSCF ports (optional)

TSCF Global Configuration

TSCF global configuration specifies the handling of idle tunnel connections. By default, the TSC server transitions an idle tunnel client from the active to the persistent state after an idle period of 300 seconds. Assuming the tunnel remains idle for an additional 330 seconds, the TSC server then transitions the tunnel from the persistent to the closed state—tearing the tunnel down and releasing its resources. If this behavior is consistent with your deployment, no changes are required or encouraged at the TSCF global configuration level. If local network conditions require modification, adjust the keepalive-timer, keepalive-timer-datagram, and tunnel-persistence-time parameters as described below.

TSCF global configuration also enables and manages high-availability (HA) topologies — topologies in which a pair of SBCs operate in tandem, one in the active and the other in the backup role to provide reliable redundant operational availability. By default, HA is disabled. If your SBC operates in standalone mode (not part of an HA pair), you can safely ignore all HA parameters and simply retain default values. If operating as part of an HA pair, use the red-port parameter to enable HA as described in the following procedure. After enabling HA, Oracle Communications recommends the retention of default values for other HA parameters (red-max-trans, red-sync-start-time, and red-sync-comp-time) unless unusual local conditions require otherwise. Prior to modifying HA parameters, you should refer to the ACLI Configuration Guide for more detailed HA information.

Use the following procedure to perform TSCF global configuration.

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

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

keepalive-timer           keepalive interval (in seconds)
keepalive-timer-datagram  keepalive interval (in seconds) for tunnels 
                          with datagram transport
tunnel-persistence-time   tunnel persistence time after disconnection 
                          (should be greater than keep-alive time)
red-port                  tscf redundancy sync port: 0 to disable and 2004
                          to enable
red-max-trans             maximum redundancy transactions to keep on active
red-sync-start-time       timeout for transitioning from standby to active
red-sync-comp-time        sync request timeout after initial sync 
                          compeletion
element-id                TSCF element Id, default : 0
options                   optional features/parameters
select                    select tscf config to edit
no                        delete tscf config
show                      show tscf config
done                      write tscf config information
exit                      return to previous menu

ORACLE(tscf-config)#

Use the keepalive-timer, keepalive-timer-datagram, and tunnel-persistence-time parameters to specify handling of idle tunnels.
The timing of SIK transmissions is defined by the TSCF global parameters, keepalive-timer-datagram and keepalive-timer. keepalive-timer-datagram is used for datagram-based (UDP) tunnels, while keepalive-timer is used for stream-based (TCP) tunnels. In the absence of a user-supplied value for keepalive-timer-datagram, keepalive-timer provides a default timer value for all tunnels regardless of the underlying transport protocol.

With SIK enabled, the server sends a keepalive message when no data is received from the client within the keepalive interval. The keepalive is sent approximately 15 seconds before timer expiration to ensure that it reaches the client before the client closes the tunnel for not receiving a keepalive message. For a datagram-based tunnel the TSC server waits 5 seconds for a keepalive response or other data from the client. If no response is received, the server sends another keepalive message. This sequence is repeated until the server receives a keepalive response or other tunnel data, or a total of 3 keepalive messages has been sent, whichever occurs first. If no keepalive response or other data is received from a client (either connection-based or datagram-based) within 15 seconds from the time the first keepalive message is sent, the server will tear down the tunnel, while saving the tunnel configuration if the if tunnel-persistence-timer registers a non-zero value.

keepalive-timer specifies the maximum idle time (defined as no transmission activity within the tunnel) before the TSC server transitions a stream-based (TCP) tunnel from the active to the persistent state. Supported values are 0 and integers within the range 30 - 550 (seconds), with a default value of 300. The special value 0 specifies that a keepalive mechanism is not employed. The integer values 30 through 550 specify the maximum size of the tolerated idle period for stream-based tunnels.

When keepalive-timer-datagram is set to its default value (0), keepalive-timer provides the default timer value for all tunnels, without regard to the transport protocol (TCP or UDP).

When keepalive-timer is set to a non-zero value, the TSC client must initiate a keepalive message exchange before an idle period exceeds the assigned non-zero value. Failure of the client to transmit a keepalive prior to the timer expiration results in the server placing the tunnel in the persistent state.

The complete keepalive message exchange consists of a client-generated Keep_Alive_Request and a server-generated Keep_Alive_Response—essentially empty control messages consisting only of address fields and a common message header.

The periodic exchange of keepalive messages not only verifies the presence of the remote tunnel peer, but also facilitates the maintenance of NAT bindings through strict firewalls.

keepalive-timer-datagram specifies the maximum idle time (defined as no transmission activity within the tunnel) before the TSC server transitions a datagram-based (UDP) tunnel from the active to the persistent state. Supported values are 0 and integers within the range 30 - 550 (seconds), with a default value of 0. The special value 0 specifies that a keepalive mechanism is not employed. The integer values 30 through 550 specify the maximum size of the tolerated idle period for datagram-based tunnels.

tunnel-persistence-time specifies the additional idle time tolerated before the TSC server transitions an idle tunnel from the persistent to the closed state and tears down the tunnel.

Allowed values are 0 and integers within the range 10 - 600 (seconds), with a default value of 330.

The value 0 specifies that the TSC server tears down the tunnel immediately upon expiration of the keep-alive timer. The integer values 10 through 600 specify the idle period, between transition from the persistent to the closed state.

During this interval, TSC clients, currently in the persistent state, can initiate a keepalive message exchange which serves to reset the keepalive timer and return the client to the active state. During this same interval, recently disconnected clients, who are still in the persistent state, can re-connect and request their previous tunnel configuration.

For efficient and predictable operation, ensure that the value assigned to tunnel-persistence-time exceeds the value assigned to keepalive-timer.
```
ORACLE(tscf-config)# keepalive-timer 30
ORACLE(tscf-config)# tunnel-persistence-time 40
ORACLE(tscf-config)#
```
Use the element-id parameter to assign a unique identifier to this TSC server.
Allowed values are 0 (the default) or an integer within the range 1 - 1023.

element-id can be safely ignored within network topologies that contain a single TSC server. However, in topologies that contain multiple TSC servers, each server must be assigned a unique network-wide identifier, provided by this parameter.

The assignment of a unique TSC server guarantees unique tunnel identifiers regardless of the number of TSC servers within the network.
```
ORACLE(tscf-config)# element-id 10
ORACLE(tscf-config)#
```
In HA topologies use the red-port, red-max-trans, red-sync-start-time, and red-sync-comp-time parameters to configure reliable redundant operations.
Use the red-port parameter to specify the UDP port number that supports TSCF synchronization message exchanges.

The default value (0) disables redundant HA configurations. Use a port value of 2004 to enable HA operations.

Use the red-max-transparameter to specify the maximum number of retained TSCF synchronization messages.

Allowed values are integers within the range 0 through 999999999 (messages) with a default of 10000.

Use the red-sync-start-time parameter to set the timer value (in milliseconds) for transition from the standby to the active role — that is the maximum period of time that the standby SBC waits for a heartbeat signal from the active SBC before assuming the active role.

Allowed values are integers within the range 0 through 999999999 (milliseconds) with a default of 5000.

Use the red-sync-comp-time attribute to specify the interval between synchronization attempts after the completion of a TSCF redundancy check.

Allowed values are integers within the range 0 through 999999999 (milliseconds) with a default of 1000.
```
ORACLE(tscf-config)# red-port 2004
ORACLE(tscf-config)# red-trans 15000
ORACLE(tscf-config)# red-sync-start-time 2500
ORACLE(tscf-config)# red-sync-comp-time 750
ORACLE(tscf-config)#
```
Use done, exit, and verify-config to complete TSCF global configuration.

TSCF Protocol Policy Configuration

Use the following procedure to configure TSCF policy-based forwarding services.

Policy-based forwarding requires the creation of a tscf-protocol-policy and the assignment of that policy to a tscf-address-pool.

From superuser mode, use the following command sequence to access cert-status-profile configuration mode. While in this mode, you configure a certificate-status-profile, a container for the information required to access a single, specific OCSP responder.
```
ACMEPACKET# configure terminal
ACMEPACKET(configure)# security
ACMEPACKET(security)# tscf
ACMEPACKET(tscf)# tscf-protocol-policy
ACMEPACKET(tscf-protocol-policy)#
```
The required name parameter differentiates tscf-protocol-policy instances from one another. Each tscf-protocol-policy specifies filtering/match criteria applied to incoming packets.
The optional ip-address parameter works in conjunction with the required port and transport-type parameters to identify incoming packets subject to this tscf-protocol-policy.
For client-side, tunneled packets, ip-address is matched against the inner packet's destination ip-address. For non-tunneled packets, ip-address is matched against the source IP-address.
For client-side, tunneled packets, port is matched against the inner packet's destination port. For non-tunneled packets, port is matched against the source port.

Retain the default value (0.0.0.0) or specify a specific IP address.
The required transport-type parameter works in conjunction with the optional ip-address and required port parameters to identify incoming packets subject to this tscf-protocol-policy.

For client-side, tunneled packets, transport-type is matched against the inner packet's transport protocol (UDP or TCP). For non-tunneled packets, transport-type is matched against the packet's transport protocol.

Retain the default value (UDP), or select TCP.
For all tunneled packets that meet the matching criteria specified by the ip-address, port, and transport-type parameters, the required realm-id parameter specifies the egress realm. Matching packets are forwarded to the gateway that services the interface associated with the named realm.
Optionally, for all packets that meet the matching criteria specified by the ip-address, port, and transport-type parameters, the tunneled packets will be forwarded to the configured remote-ip-address. The destination IP address of the detunneled packet will be changed to this value.
When the packets are coming from non-tunneled side to tunneled side, the source IP address must match the remote-ip-address. The source IP address will be changed back to the original destination IP address within the tunneled packet
Use done, exit, and verify-config to complete configuration of this tscf-protocol-policy.
Repeat Steps 1 through 7 to configure additional tscf-protocol-policies if necessary.
For instructions on how to assign a TSCF protocol policy to a TSCF address pool, see the section TSCF Address Pool Configuration in this document. The parameter is called protocol-policy,and appears in Step 1 and Step 9.

TSCF Address Pool Configuration

During the configuration stage as described in TSCF Overview, the TSC server assigns a tunnel IP address to the client application. These assigned addresses are obtained by the TSC server from a tscf-address-pool, a configuration object that contains an IP address list. The IP address list contains one or more IP address ranges. Each address range consists of contiguous IP addresses, and can contain a minimum of 1, or a maximum of 262,144 list entries for IPv4 or IPv6.

The address range size, the list size, and the size of the tscf-address-pool are constrained by the same maximum value. Consequently, while the IP address list can contain one or several ranges, the total number of IP addresses contained in the individual address ranges cannot exceed 262,144.

Use the following required procedure to configure a tscf-address-pool configuration object. Later, you will assign the address pool to a specific TSCF interface.

From superuser mode, use the following command sequence to access tscf-address-pool configuration mode.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# tscf
ORACLE(tscf)# tscf-address-pool
ORACLE(tscf-address-pool)#

name            name for the tscf address pool
address-range   address ranges for the local address pool
dns-realm-id    dns realm identifier for local-pool
data-flow       data flow name for managing data traffic with the pool
protocol-policy comma separated protocol policy name/s for managing 
                specific protocol traffic with the pool
batch           enter all arguments on one line
select          select a local address pool to edit
no              delete selected local address pool
show            show selected local address pool
done            write local address pool information
exit            return to previous menu

ORACLE(tscf-address-pool)#

Use the name parameter to provide a unique identifier for this tscf-address-pool.
```
ORACLE(tscf-address-pool)# name tscf-lap-1
ORACLE(tscf-address-pool)#
```
Retain the default value (an empty string) for the dns-realm-id parameter.

Use the address-range parameter to access address-range sub-configuration mode. While in this mode, you compile an IP address list, and assign contiguous ranges of IP addresses to the list.

ORACLE(tscf-address-pool)# address-range
ORACLE(tscf-address-range)# ?
network-address base network address (IPv4/IPv6) for this range
subnet-mask     subnet mask for address range
batch           enter all arguments on one line
select          select a local address pool address range to edit
no              delete selected local address pool range
show            show selected local address pool range
done            write local address pool range information
exit            return to previous menu

ORACLE(tscf-address-range)#

Use the network-address and subnet-mask ACLI parameters to specify a contiguous range of IP addresses assigned to this tscf-address-pool.

network-address can take any valid IP address value. subnet-mask values should take into consideration the projected number of tunnels to be supported by TSCF ports. To ensure that IP address lists do not exceed the maximum supported value (262,144), mask values must begin with the initial 14 bits set to 1. The following table lists supported subnet-mask values along with the size of the resulting address pool.

Supported subnet-mask Values Address Pool Size

255.252.0.0	                        262,144
255.254.0.0	                        131,072
255.255.0.0	                         65,536
255.255.128.0	                       32,768
255.255.192.0	                       16,384
255.255.224.0	                        8,192
255.255.240.0	                        4,096
255.255.248.0	                        2,048
255.255.252.0	                        1,024
255.255.254.0	                          512
255.255.255.0	                          256
255.255.255.128	                        128
255.255.255.192	                         64
255.255.255.224	                         32
255.255.255.240	                         16
255.255.255.248	                          8
255.255.255.252	                          4
255.255.255.254	                          2
255.255.255.255	                          1

This command example allocates the maximum allowed address range to current the IP address list.

ORACLE(tscf-address-pool)# network-address 10.244.0.0
ORACLE(tscf-address-pool)# subnet-mask 255.252.0.0
ORACLE(tscf-address-pool)#

This command example allocates 4096 IP addresses to the IP address list.

ORACLE(tscf-address-pool)# network-address 10.244.0.0
ORACLE(tscf-address-pool)# subnet-mask 255.255.240.0
ORACLE(tscf-address-pool)#

Use done and exit to add the address range to the IP address list, and to return to tscf-address-pool configuration mode.
If necessary, repeat Steps 5 and 6 to add additional contiguous address ranges to the IP address list.
This command example allocates a second range of 16,384 IP addresses, to the IP address list.
```
ORACLE(tscf-address-pool)# network-address 172.16.240.0
ORACLE(tscf-address-pool)# subnet-mask 255.255.192.0
ORACLE(tscf-address-pool)#
```
Use the data-flow parameter to assign a specific tscf-data-flow to this tscf-address-pool.
Refer to TSCF Data Flow Configuration for configuration details.
```
ORACLE(tscf-address-pool)# data-flow tscf-df-1
ORACLE(tscf-address-pool)#
```
Use the protocol-policy parameter to assign specific protocol traffic to the pool. Use the name of the policy that was assigned to it when it was created. If assigning multiple policies, use a comma separated list.
```
ACMEPACKET(tscf-address-pool)# protocol-policy <tscf-address-policy>
```
Use done, exit, save, and verify-config to complete configuration of the tscf-address-pool instance.

verify-config confirms that a valid IP address and subnet mask are present in each IP address list, and that the total number of IP addresses contained in the list does not exceed 261,144. If the verification process finds errors, verify-config issues appropriate explanatory error messages.
Repeat Steps 1 through 10 to configure additional tscf-address-pool instances.

TSCF Data Flow Configuration

Use the following procedure to configure an optional tscf-data-flow object. If you are not using tscf-data-flows to provide to provide static egress routes, this procedure can be safely ignored.

From superuser mode, use the following command sequence to access tscf-data-flow configuration mode. In this mode you configure tscf-data-flows that enable static pass-thru of tunneled data via a specified realm.

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# tscf
ORACLE(tscf)# tscf-data-flow
ORACLE(tscf-data-flow)# ?
name            name for a data flow
realm-id        realm-id to route the upstream data flow
group-size      the number of UEs to be managed by the data flow
upstream-rate   Upstream bandwidth (KB/s) for the data flow
downstream-rate Downstream bandwidth (KB/s) for the data flow
batch           enter all arguments on one line
select          select a data flow to edit
no              delete selected data flow
show            show selected data flow
done            write data flow information
exit            return to previous menu

ORACLE(tscf-data-flow)#

Use the name parameter to provide a unique identifier for this tscf-data-flow instance.
```
ORACLE(tscf-data-flow)# name tscf-dt-01
ORACLE(tscf-data-flow)#
```

Use the realm-id parameter to identify the egress realm.

ORACLE(tscf-data-flow)# realm-id core-1
ORACLE(tscf-data-flow)#

Use the group-size parameter to specify the size and number of address blocks supported by this data-flow instance.
The size of the associated tscf-address-pool (defined as the number or IPv4 addresses contained in the pool), is divided by the group-size value to segment the address pool into smaller address blocks. After determining the start address for each block, the SBC establishes two static flows for each of the address blocks — a downstream flow, in the access direction, and an upstream flow generally toward a core application server gateway/router that provides forwarding service for pass-thru data-flow.

As a result of the static-flow establishment, each address block consumes 4 NAT entries, 2 for the downstream flow and 2 for the upstream flow. Because the current software release imposes a maximum restriction of 4096 NAT entries per data-flow instance, dividing 4096 by 4 provides the largest number of supported address blocks, 1024.

Use the following table to associate supported group-size values with address pool size.

For example, for IPv4 addressing:

The largest supported address pool (262,144 addresses) requires a group size of 256 addresses, which produces the maximum 1,024 address blocks with each block containing 256 addresses.

An address pool containing 131,072 addresses can be segmented as 512 address blocks, with each block containing 256 addresses, or as 256 blocks, with each block containing the maximum 1,024 addresses.

An address pool containing 1,024 addresses can be segmented as follows:

1 block containing 1,024 addresses

2 blocks containing 512 addresses

4 blocks containing 256 addresses

8 blocks containing 128 addresses

16 blocks containing 64 addresses

32 blocks containing 32 addresses

64 blocks containing 16 addresses

128 blocks containing 8 addresses

256 blocks containing 4 addresses
```
Address Pool Size	Supported group-size Values
262,144	                                  256
131,072                             	128, 256
65,536	                          64, 128, 256
32,768                      	32, 64, 128, 256
16,384                  	16, 32, 64, 128, 256
8,192                 8, 16, 32, 64, 128, 256
4,096              4, 8, 16, 32, 64, 128, 256
2,048	          2, 4, 8, 16, 32, 64, 128, 256
1,024       	1, 2, 4, 8, 16, 32, 64, 128, 256
512         	1, 2, 4, 8, 16, 32, 64, 128, 256
256         	1, 2, 4, 8, 16, 32, 64, 128, 256
128              	1, 2, 4, 8, 16, 32, 64, 128
64                    	1, 2, 4, 8, 16, 32, 64
32                        	1, 2, 4, 8, 16, 32
16                            	1, 2, 4, 8, 16
8                                 	1, 2, 4, 8
4                                    	1, 2, 4
2                                       	1, 2
1                                          	1
ORACLE(tscf-data-flow)# group-size 128
ORACLE(tscf-data-flow)#
```
Use the upstream-rate parameter to specify the allocated upstream (core-side) bandwidth.
Allowable values are integers within the range 0 (the default) through 122070 (KB/s).

The 0 value allocates all available upstream bandwidth.
```
ORACLE(tscf-data-flow)# upstream-rate 100
ORACLE(tscf-data-flow)#
```
Use the downstream-rate parameter to specify the allocated downstream (access-side) bandwidth.
Allowable values are integers within the range 0 (the default) through 122070 (KB/s).

The 0 value allocates all available downstream bandwidth.
```
ORACLE(tscf-data-flow)# downstream-rate 100
ORACLE(tscf-data-flow)#
```
Use done, exit, and verify-config to complete configuration of this tscf-data-flow instance.

verify-config confirms that the total number of IPv4 addresses assigned to the data-flow instance does not exceed 262,144 and that the total number of NAT entries consumed by the data-flow instance does not exceed 4,096. In the event of discrepancies, verify-config issues an error message recording the actual number of IPv4 addresses and/or the number of NAT entries.

Repeat Steps 1 through 7 to configure additional tscf-data-flow instances.

TLS Profile Configuration

Use the following required procedure to configure a tls-profile configuration object that identifies the cryptographic resources, specifically certificates and protocols, required for tunnel creation. Later, you will assign the tls-profile to a specific TSC port.

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

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# tls-profile
ORACLE(tls-profile)# ?

name                      tls profile name
end-entity-certificate    end entity certificate for the TLS connection
trusted-ca-certificates   list of trusted certificate records
cipher-list               list of ciphers
verify-depth              maximum length of the certificate chain
mutual-authenticate       mutually authenticate
tls-version               TLS version
options                   optional features/parameters
cert-status-check         cert status check state
cert-status-profile-list  list of cert-status-profiles for status requests
ignore-dead-responder     Ignore dead cert status responder
allow-self-signed-cert    allow self-signed certificate
select                    select configuration to edit
no                        delete configuration
show                      show configuration information
done                      write configuration information
quit                      quit out of configuration mode
exit                      return to previous menu

ORACLE(tls-profile)#

Use the name parameter to provide a unique identifier for this tls-profile.
```
ORACLE(tls-profile)# name tscfTls01
ORACLE(tls-profile)#
```
Use the required end-entity-certificate parameter to supply the unique name of a certificate-record configuration element referencing the identification credential (specifically, an X509.v3 certificate) offered by the TSC server in support of its asserted identity.
```
ORACLE(tls-profile)# end-entity-certificate tscfServerCert01
ORACLE(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 a client application.
Provide a comma separated list of existing CA certificate-record configuration elements.
```
ORACLE(tls-profile)# trusted-ca-certificates verisignClass3-a,verisignClass3-b,baltimore,thawtePremium
ORACLE(tls-profile)#
```
Specify the list of supported ciphers, or retain the default value, DEFAULT.
Use the verify-depth parameter to specify the maximum number of chained certificates that will be processed while authenticating the client application.

Provide an integer within the range 1 through 10 (the default).

The TSC server supports the processing of certificate chains when X.509v3 certificate-based authentication is used during tunnel establishment. The following process validates a received TLS certificate chain.
1. 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
2. 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.
3. 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.
4. 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.
5. Check the X509v3 Extensions field to verify that the current certificate identifies a CA. If not so, authentication fails; otherwise, continue chain validation.
6. 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).
7. Compute the same MD5 hash. If the results are not identical, authentication fails; otherwise, continue chain validation.
8. 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.
```
ORACLE(tls-profile)# verify-depth 8
ORACLE(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.
```
ORACLE(tls-profile)# mutual-authenticate disabled
ORACLE(tls-profile)#
```
Retain the default value, compatibility, for the tls-version parameter.
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.

TSCF OCSP Configuration

The following steps provide instruction on using the ACLI to configure OCSP-based certificate revocation services.

Providing OCSP services requires the creation of a secure TLS connection between a TSC port and one or more OCSP responders. This configuration is a three-step process.

Create one or more certificate-status-profiles. Each certificate-status-profile provides the information and cryptographic resources required to access a single OCSP responder.
Assign one or more certificate-status-profiles to a tls-profile. This tls-profile enables OCSP services and provides a list of one or more OCSP responders.
Assign the tls-profile to a TSCF port to enable OCSP service on that port.

Configure a certificate-status-profile

From superuser mode, use the following command sequence to access status-profile. cert-status-profile configuration mode. While in this mode, you configure a certificate-status-profile, a container for the information required to access a single, specific OCSP responder.
```
ACMEPACKET# configure terminal
ACMEPACKET(configure)# security
ACMEPACKET(security)# cert-status-profile
ACMEPACKET(cert-status-profile)#
```
The required name parameter differentiates certificate-status-profile instances from one another. Each certificate-status-profile provides configuration information for a single, specific OCSP responder.
The type parameter selects the certificate revocation check methodology; the only currently supported value is OCSP.
Retain the default value (http) for the trans-protocol parameter, which identifies the transport method used to access the OCSP responder.
The ip-address parameter works in conjunction with the port parameter to locate the OCSP responder.

ip-address identifies the OCSP responder by its IP address. port identifies the port monitored by the responder for incoming OCSP requests.

Allowable port values are integers within the range 1025 through 65535. In the absence of an explicitly configured value, a default value of 80, the well-known HTTP port, is provided.
The realm-id parameter specifies the realm used to transmit OCSP requests and receive OCSP responses. In the absence of an explicitly configured value, the default value of wancom0, specifying OCSP protocol transmissions across the wancom0 management interface, is used.
The requester-cert parameter is meaningful only if OCSP requests are signed; ignore this parameter if requests are not signed. RFC 2560 does not require the digital signature of OCSP requests. OCSP responders, however, can impose signature requirements.
If a signed request is required by the OCSP responder, provide the name of the certificate configuration element that references the certificate used to sign OCSP requests.
The responder-cert parameter identifies the certificate used to validate signed OCSP response -- a public key of the OCSP responder. RFC 2560 requires that all OCSP responders digitally sign OCSP responses, and that OCSP requesters validate incoming signatures.
Provide the name of the certificate configuration element that references the certificate used to validate the signed OCSP response.
The retry-count parameter specifies the maximum number of times to retry an OCSP responder in the event of connection failure. If the retry counter specified by this parameter is exceeded, the OCSP requester contacts another responder (if multiple responders have been configured) and quarantines the unavailable responder for a period defined by the dead-time parameter.

In the absence of an explicitly configured value (an integer within the range 0 through 10), the default value of 1 (connection retries) is used.
The dead-time parameter specifies the quarantine period imposed on an unavailable OCSP responder. During the quarantine period, the TSC server will not send OCSP requests to the OCSP responder. In the absence of an explicitly configured value (an integer within the range 0 through 3600 seconds), the default value of 0 (no quarantine period) is used.

Note:
Customer implementations utilizing a single OCSP responder are encouraged to retain the default value of the dead-time parameter, or to specify a brief quarantine period to prevent lengthy service outages.
The hostname and trusted-ca parameters can be safely ignored.
Use done, exit, and verify-config to complete configuration of this certificate-status-profile.
Repeat Steps 1 through 12 to configure additional certificate-status-profiles if necessary.

Assign the certificate-status-profile to a TLS profile

From superuser mode, use the following command sequence to access tls-profile configuration mode. While in this mode, you can alter an existing TLS profile to support OCSP transactions.
Use the select command to identify a specific tls-profile that will support OCSP requests and responses.
Set the mutual-authenticate parameter to enabled.
Use the cert-status-check parameter to enable certificate status checking on this tls-profile.

Set this parameter to enabled.
Use the cert-status-profile-list parameter to assign an OCSP responder or responders to this TLS profile.
For example, this ACLI sequence assigns a single OCSP responder.
```
ACMEPACKET(tls-profile)#cert-status-profile-list "OCSP_Symantic OCSP_Thawte OCSP_Entrust"
ACMEPACKET(tls-profile)#
```
Each assigned certificate-status-profile contains the data needed to access a single OCSP responder. Responders are accessed in list order, from first to last. In the above example, the TSC server first contacts the Symantic OCSP responder. If the responder cannot be contacted within the limits specified by the retry-count parameter of the certificate-status-profile, the responder is quarantined for the time specified by the dead-time parameter, and the TSC server moves to the next list entry.
Use done, exit, and verify-config to complete this configuration.
If necessary, repeat this procedure to prepare other TLS profiles for OCSP-based certificate checking support.

Assign the tls-profile to a TSCF port

From superuser mode, use the following command sequence to access tscf-port configuration mode. While in this mode, you assign an existing TLS profile to a TSCF port.
Use the select command to identify a specific tscf port that will support OCSP requests and responses.
Use the tls-profile parameter to assign an OCSP-enabled tls-profile to the current TSCF port enabled.
Use done, exit, and verify-config to complete configuration.
If necessary, repeat this procedure to prepare other TSCF ports for OCSP-based certificate checking support.

Sample OCSP Configurations

certificate-status-profile configuration

A sample certificate-status-profile configuration follows:

ACMEPACKET# show running-config cert-status-profile
cert-status-profile
					name                                    OCSP_Symantic
     ip-address                              192.0.2.100
     hostname
     port                                    8080
     type                                    OCSP
     trans-proto                             HTTP
     requestor-cert                          signOCSP
     responder-cert                          SymanticPublic-1
     trusted-cas
     realm-id                                wancom0
     retry-count                             1
     dead-time                               60
     last-modified-by                        admin@console
     last-modified-date                      2014-07-24 18:25:25
task done
ACMEPACKET#

This configuration creates a certificate-status-profile named OCSP_Symantic. The profile identifies an OCSP responder located at 192.0.2.100:8080. The required responder-cert parameter specifies the CA public certificate used by the TSC server to verify the signed OCSP response. The optional requester-cert parameter indicates that the OCSP responder requires signed requests, and identifies the certificate used by the TSC server to digitally sign OCSP requests. The optional dead-time parameter imposes a 60 second quarantine if the OCSP responder is unreachable. Retention of default values for the realm-id and retry-count parameters specify OCSP responder access via the wancom0 management interface and a retry count of 1.

tls-profile configuration

A sample tls-profile configuration follows:

ACMEPACKET# show running-config tls-profile
tls-profile
        name                                    TLS_OCSP
        end-entity-certificate                  TSCFCert_1
        trusted-ca-certificates                 CA_Symantic
                                                CA_Thawte
                                                CA_Entrust
                                                CA_DigiSign
        cipher-list                             All
        verify-depth                            10
        mutual-authenticate                     enabled
        tls-version                             compatibility
        cert-status-check                       enabled
								cert-status-profile-list																OCSP_Symantic
                                                OCSP_Thawte
        ignore-dead-responder																			disabled
        allow-self-signed-cert																		disabled
        last-modified-by																								admin@console
        last-modified-date																						2014-07-24 19:40:37
task done
ACMEPACKET#

This configuration creates a tls-profile named TLS_OCSP. The profile uses the mutual-authenticate parameter to enable mutual authentication between the TSC server and the OCSP responders, the cert-status-check parameter to enable OCSP services, and the cert-status-profile-list parameter to identify three OCSP responders.

sample portion of a tscf-interface/tscf-port configuration

A sample portion of a tscf-interface/tscf-port configuration follows:

 ACMEPACKET# show running-config tscf-interface
tscf-interface
     realm-id                             access
     state                                enabled
     max-tunnels                          200000
     local-address-pools                  pool1
   		nagle-state                          enabled
     assigned-services                    SIP,redundancy,DDT,
                                          server-keepalive
					tscf-port
       	address                           172.16.21.2
        port                              443
        transport-protocol                TLS
        tls-profile                       TLS_OCSP
...
...
...
        last-modified-by                    admin@console
        last-modified-date                  2014-07-24 19:51:03
task done
ACMEPACKET#

This configuration enables OCSP support on the TSCF port 172.16.21.2:443.

Monitoring OCSP Operations

The TSC server generates an SNMP trap when a configured OCSP responder becomes Operations unreachable. It generates second trap when connectivity is re-established with a previously unreachable OCSP responder.

The show security ocsp stats ACLI command provides OCSP operational counts.

ACMEPACKET#show security ocsp stats
18:49:34-147
CERTD OCSP Statistics                        ---- Lifetime ----
                                        Recent        Total    PerMax
Req Rcvd from Cavium                        0           0         0
Resp Sent to Cavium                         0           0         0
OCSP Req Sent                               0           0         0
OCSP Resp Rcvd                              0           0         0
OCSP Timeout                               	0           0         0
Duplicate OCSP Request                     	0           0         0
OCSP Status-Good                           	0           0         0
OCSP Status-Revoked                        	0           0         0
OCSP Status-Unknown                        	0           0         0

Key to OCSP Operational Counts:

Req RCVD from Cavium—Number of certificates presented to the OCSP task for verification.
Resp Sent to Cavium—Number of valid responses (good, revoked, unknown) received from OCSP responders.
OCSP Req Sent—Number of requests sent to OCSP responders.
OCSP RespRcvd—Number of responses received from OCSP responders.
OCSP Timeout—Number of unanswered OCSP requests plus the number of internal timeouts.
OCSP Status-Good—Number of good status responses received from OCSP responders.
OCSP Status-Revoked—Number of revoked status responses received from OCSP responders.
OCSP Status-Unknown—Number of unknown status responses received from OCSP responder.

TSCF Interface Configuration

TSCF interface configuration specifies the SBC IP address that is accessed by TSC clients to initiate tunnel creation, assigns resources that facilitate tunnel creation, identifies specific TSCF services offered by the interface, and limits the number of supported tunnels.

Use the following procedure to configure a TSCF interface—keeping in mind that

a TSCF interface must be physically supported by an ETC NIU with a minimum of 8GB of installed DRAM
a TSCF interface and SIP interface cannot coexist on the same network interface

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

ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# tscf
ORACLE(tscf)# tscf-interface
ORACLE(tscf-interface)# ?

realm-id              realm identifier
state                 state
max-tunnels           maximum number of tunnels
local-address-pools   address pool name
assigned-services     comma-separated list of services
options               optional features/parameters
tscf-ports            list of TSCF ports
select                select tscf config to edit
no                    delete tscf config
show                  show tscf config
done                  write tscf config information
exit                  return to previous menu

ORACLE(tscf-interface)#

Use the optional state parameter to select the TSCF interface operational state.
Supported values are enabled (the default) | disabled.

Retain the default value to place the TSCF interface in an active operational state. Use disabled to place the TSCF interface in a non-operational state.
```
ORACLE(tscf-interface)# state enabled
ORACLE(tscf-interface)#
```
Use the required realm-id parameter to identify the realm that supports TSC client access to the SBC.
Enter the realm name.
```
ORACLE(tscf-interface)# realm-id tsmAccess
ORACLE(tscf-interface)#
```
Use the optional nagle-state parameter to select the operational mode of the Nagle algorithm on this TSCF interface.
Retain the default value (enabled) to support Nagle algorithm operations on this interface; use the alternate value (disabled) to disable algorithm operations.
```
ORACLE(tscf-interface)# nagle-state disabled
ORACLE(tscf-interface)#
```
Use the optional assigned-services parameter to enable one of more services supported by this TSCF interface. Currently supported services are ddt (refer to Dynamic Datagram Tunneling), nagle (refer to The show tscf statistics, show tscf tunnel all, and show tscf tunnel detailed ACLI commands all provide various counts of HA tunnel restoration operations.), redundancy (refer to Tunnel Redundancy), server-keepalive (refer to Server-Initiated Keepalive), and sip.
Retain the default value, sip, to enable tunneling of SIP traffic.

Use the keyword, ddt, to enable the establishment of a linked tunnel pair—a persistent TCP/TLS tunnel to carry signalling data, and an on-demand UDP/DTLS tunnel for datagram traffic.

Use the keyword, nagle, to support the override of the TSCF-interface-specific Nagle algorithm state (enabled | disabled) on an individual tunnel.

If nagle is specific as an assigned service, the ACLI verify-config command issues a warning if it fails to find an existing TCP/TLS port.

Use the keyword, redundancy, to enable tunnel redundancy for improved call quality under adverse packet loss.

Use the keyword, server-keepalive, to enable the periodic generation of TSCF-initiated keepalive messages on an idle tunnel — defined as no transmission activity within the tunnel.

To enable multiple services, for example SIP and tunnel redundancy, use sip,redundancy. The required comma (,) serves as an argument delimiter.
```
ORACLE(tscf-interface)# assigned-services sip,redundancy
ORACLE(tscf-interface)#
```
To enable dynamic datagram tunneling, use sip,ddt.
```
ORACLE(tscf-interface)# assigned-services sip,ddt
ORACLE(tscf-interface)#
```
Use the optional max-tunnels parameter to specify the maximum number of concurrent tunnels supported by this TSCF interface.
This parameter allows available tunnel capacity to be allocated across multiple realms.

The special value, 0, indicates that the interface-specific limit is bounded only the licensed value.
```
ORACLE(tscf-interface)# max-tunnels 20000
ORACLE(tscf-interface)#
```
Use the required local-address-pools parameter to identify the local address pool that provides tunnel addresses to TSC clients.
A specific address from the address pool will be transmitted to the TSC client as part of the tunnel creation process. This address provides the inner source address for tunneled packets originated by the TSC client application.

Refer to TSCF Address Pool Configuration for address pool details.
```
ORACLE(tscf-interface)# local-address-pools tscfPool172
ORACLE(tscf-interface)#
```

Use the tscf-port parameter to move to tscf-port configuration mode.

ORACLE(tscf-interface)# tscf-port
ORACLE(tscf-port)# ?

address              IP Address
port                 port
transport-protocol   transport protocol
tls-profile          tls profile name
select               select a tscf port to edit
no                   delete selected tscf port
show                 show tscf port information
done                 write tscf port information
exit                 return to previous menu

ORACLE(tscf-port)#

Use the required address and port parameters to specify the IP address and port number monitored for incoming tunnel client messages.
This address and port number will be transmitted to the TSC client as part of the tunnel creation process. This address provides the outer destination address for tunneled packets originated by the TSC client application.

The TSCF port IP address must match the address range of the realm designated by the realm-id parameter. As previously stated, the physical interface must be provided by an ETC NIU.

Enter a currently configured IP address and a port number with the range 1025 through 65535, with a default value of 5060.
```
ORACLE(tscf-port)# address 192.168.11.22
ORACLE(tscf-port)# port 443
ORACLE(tscf-port)#
```
Use the optional transport-protocol parameter to identify the tunnel transport protocol.
Supported values are TLS (the default, TCP/TLS) | DTLS (UDP/DTLS) | TCP | UDP.

Note:
The unsecured TCP and UDP protocols are only used for debug purposes, and are not intended for operational environments.
```
ORACLE(tscf-port)# transport-protocol TLS
ORACLE(tscf-port)#
```
If the transport-protocol parameter is either TLS or DTLS, use the required tls-profile parameter to identify the TLS profile that specifies the cryptographic resources available to support TLS or DTLS operations.
If the specified tunnel transport protocol is either TCP or UDP (non-operational environments only), this parameter can be safely ignored.

Refer to TLS Profile Configuration for details.
```
ORACLE(tscf-port)# tls-profile tscfTLS01
ORACLE(tscf-port)#
```
Use done and exit to return to tscf-interface configuration mode.
If required, repeat Steps 7 through 11 to configure additional TSCF ports.
Use done, exit, and verify-config to complete tscf-interface configuration.
When validating the tscf-interface configuration verify-config confirms the following:
- the presence of an ETC NIU equipped with a minimum of 8GB of installed DRAM, and issues an ERROR: MINOR ALARM message if a compliant NIU is absent
- the realm specified by the realm-id parameter actually exists, and issues an error message in the case of a non-existent realm
- the TSCF port address matches the address specified by the realm-id parameter
- the presence of an associated SIP Interface, and issues an error message in the case of a non-existent realm
- the TSCF address pool specified by the local-address-pool parameter actually exists, and issues an error message in the case of a non-existent address pool
- the TSCF address pool is not mis-configured, and issues an error message if it is
- the presence of one or more configured tscf-ports, and issues a warning message in the event of a missing port
- if assigned-services is ddt,sip, the configuration of matching (same address and port values) stream-based and datagram-based tunnels — issues an error message in the case of a missing tunnel
- if transport-protocol is TLS or DTLS, the assignment of a TLS profile to the port — issues an error message in the case of a no assignment or the assignment of a non-existent profile
verify-config confirms that TSCF and SIP interfaces have not been configured on the same network interface. In the event of such a conflict, verify-config issues an ERROR message identifying the TSCF interface, the SIP interface, and the network interface by name. Additionally, verify-config places the TSCF interface in an inactive state, where it remains until the configuration has been repaired.
Repeat Steps 1 through 14 to configure additional tscf-interfaces as required.

STG Configuration

From superuser mode, use the following command path to access assigned-services configuration mode.
```
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# tscf
ORACLE(security)# tscf-interface
ORACLE (tscf-interface)# select
<RealmID>:
1: access 172.168.31.99:7000
selection:  1
ACMEPACKET (tscf-interface)# assigned-services STG
```
Note:
There are other assigned services that may be listed in addition to STG. These include SIP, redundancy, and DDT. The list must be comma delimited. Example: SIP, STG

inter-client-block Configuration

From superuser mode, use the following command path to access assigned-services configuration mode.
```
ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# tscf
ORACLE(tscf)# tscf-interface
ORACLE (tscf-interface)# select
<RealmID>:
1: access 172.168.31.99:7000
selection:  1
ACMEPACKET (tscf-interface)# assigned-services inter-client-block
```
Note:
In order to add inter-client-block to an existing list of assigned services, ensure that each service attribute is delimited by a comma. Example: SIP,STG,inter-client-block.

TSCF DoS Protection Configuration

Use the following procedure to configure DoS protection as described in Denial of Service. DoS protection is assigned via the realm that supports the TSCF port.

From superuser mode, use the following command sequence to access realm configuration mode.

ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# realm-config
ORACLE(realm-config)#

Use the select command to identify the target realm, the realm supporting the TSCF port.

ORACLE(realm-config)# select 
...
...
3. tsmAccess
...
...
ORACLE(realm-config)# 3
ORACLE(realm-config)#

Use the access-control-trust-level parameter to enable DoS protection.
Set the parameter to high to enable DoS protection.
```
ORACLE(realm-config)# access-control-trust-level high
ORACLE(realm-config)#
```
Use done, exit, and verify-config to complete DoS configuration for the current realm.
Repeat Steps 1 through 4 to enable DoS on other TSCF ports.