1. Configuration Guide
  2. Security
  3. Key Exchange Protocols

Key Exchange Protocols

Key exchange protocols enable secure communications over an untrusted network by deriving and distributing shared keys between two or more parties. The Internet Key Exchange (IKEv1) Protocol, originally defined in RFC 2409, provides a method for creating keys used by IPsec tunnels. Session Description Protocol Security Descriptions for Media Streams (SDES), defined in RFC 4568, provides alternative methods for creating keys used to encrypt Real-time Transport Protocol (RTP) and Real-time Transport Control Protocol (RTCP) transactions.

Each of these protocols is described in the following sections.

IKEv1 Protocol

IKEv1 is specified by a series of RFCs, specifically RFCs 2401 through 2412. The most relevant are:

  • RFC 2407, The Internet IP Security Domain of Interpretation for ISAKMP
  • RFC 2408, Internet Security Association and Key Management Protocol (ISAKMP)
  • RFC 2409, The Internet Key Exchange (IKE)
  • RFC 2412, Oakley Key Determination Protocol

IKEv1 combines features of the Internet Security Association and Key Management Protocol (ISAKMP) and Oakley Key Determination Protocol in order to negotiate Security Associations (SA) for two communicating peers. IKEv1 also provides for key agreement using Diffie-Hellman.

IKEv1 uses two phases. Phase 1 is used to establish an ISAKMP Security Association for IKEv1 itself. Phase 1 negotiates the authentication method and symmetric encryption algorithm to be used. Phase 1 requires either six messages (main mode) or three messages (aggressive mode).

Phase 2 negotiates the SA for two IPsec peers and is accomplished with three messages.

The initial IKEv1 implementation supports RFC 2409, Internet Key Exchange, and RFC 3706, A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers.

IKEv1 Configuration

IKEv1 configuration consists of five steps.

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

IKEv1 Global Configuration

To configure global IKEv1 parameters:

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

    Use 1 to specify IKEv1 operations.

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

    Events are listed below in descending order of criticality.

    • emergency (most critical)
    • critical
    • major
    • minor
    • warning
    • notice
    • info (least critical — the default)
    • trace (test/debug, not used in production environments)
    • debug (test/debug, not used in production environments)
    • detail (test/debug, not used in production environments)

    In the absence of an explicitly configured value, the default value of info is used.

  4. Use the optional udp-port parameter to specify the port monitored for IKEv1 protocol traffic.

    In the absence of an explicitly configured value, the default port number of 500 is used.

  5. Use the optional negotiation-timeout parameter to specify the maximum interval (in seconds) between Diffie-Hellman message exchanges.

    In the absence of an explicitly configured value, the default specifies a 15 second timeout value.

  6. Use the optional event-timeout parameter to specify the maximum time (in seconds) allowed for the duration of an IKEv1 event, defined as the successful establishment of an IKE or IPsec Security Association (SA).

    In the absence of an explicitly configured value, the default specifies a 60 second time span.

  7. Use the optional phase1-mode parameter to specify the IKE Phase 1 exchange mode.

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

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

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

    In the absence of an explicitly configured value, the default (main mode) is used.

  8. Use the optional phase1-dh-mode parameter to specify the Diffie-Hellman Group used during IKE Phase 1 negotiation.

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

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

    first-supported — (the default) as responder, use the first supported Diffie-Hellman group proposed by initiator

  9. If functioning as the IKE initiator, use the optional phase1-life-seconds parameter to specify the proposed lifetime (in seconds) for the IKE SA established during IKE Phase 1 negotiations.

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

    This parameter can safely be ignored if functioning as a IKE responder.

  10. If functioning as the IKE responder, use the optional phase1-life-seconds-max parameter to specify the maximum time (in seconds) accepted for IKE SA lifetime during IKE Phase 1 negotiations.

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

    This parameter can safely be ignored if functioning as a IKE initiator.

  11. If functioning as the IKE initiator, use the optional phase2-life-seconds parameter to specify the proposed lifetime (in seconds) for an IPsec SA established during IKE Phase 2 negotiations.

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

    This parameter can safely be ignored if functioning as a IKE responder.

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

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

    This parameter can safely be ignored if functioning as a IKE initiator.

  13. Use the optional phase2-exchange-mode parameter to specify the Diffie-Hellman group used in Phase 2 negotiations.

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

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

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

    Note:

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

    phase1-group — (the default) use the same Diffie-Hellman group as used during Phase 1 negotiation

  14. Use the shared-password parameter to specify the PSK (pre-shared key) used during authentication with the remote IKE peer.

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

    This global PSK can be over-ridden by an interface-specific PSK.

  15. Use the optional dpd-time-interval parameter to specify the maximum period of inactivity before the DPD protocol is initiated on a specific endpoint.

    Note:

    DPD only works with IPv6.

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

    The default value, 0, disables the DPD protocol; setting this parameter to a non-zero value globally enables the protocol and sets the inactivity timer.

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

DPD Protocol Configuration

If you enabled the DPD protocol with the dpd-time-interval parameter, use the following procedure to create a DPD template, an operational set of DPD parameters, that you subsequently assign to one or more IKEv1 interfaces.

Note:

DPD only works with IPv6.
  1. Access the dpd-params configuration parameter. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ike
ORACLE(ike)# dpd-params
ORACLE(dpd-params)#
  2. name—Provide a unique identifier for this dpd-params instance.
  3. max-loop—Specify the maximum number DPD peers examined every dpd-interval, whose value is established during IKv1 global configuration.

    If CPU workload surpasses the threshold set by max-cpu-limit, this value is over-ridden by load-max-loop.

    Allowable values are within the range 1 through 999999999 (endpoints) with a default of 100.

  4. max-endpoints—Specify the maximum number of simultaneous DPD protocol negotiations supported when the CPU is not under load (as specified by the max-cpu-limit property).

    If CPU workload surpasses the threshold set by max-cpu-limit, this value is over-ridden by load-max-endpoints.

    Allowable values are within the range 1 through 999999999 (endpoints) with a default of 25.

  5. max-cpu-limit—Specify a threshold value (expressed as a percentage of CPU capacity) at which DPD protocol operations are minimized to conserve CPU resources.

    Allowable values are within the range 0, which disables DPD operations, through 100 (percent) with a default of 60.

  6. load-max-loop—Specify the maximum number of endpoints examined every dpd-time-interval when the CPU is under load, as specified by the max-cpu-limit parameter.

    Allowable values are within the range 1 through 999999999 (endpoints) with a default of 40. Ensure that the configured value is less than the value assigned to max-loop.

  7. load-max-endpoints—Specify the maximum number of simultaneous DPD Protocol negotiations supported when the CPU is under load, as specified by the max-cpu-limit property.

    Allowable values are within the range 1 through 999999999 (endpoints) with a default of 5. Ensure that the configured value is less than the value assigned to max-endpoints.

  8. Type done, exit, and verify-config to complete configuration of the DPD template instance.
  9. Repeat Steps 1 through 8 to configure additional DPD templates.

IKEv1 Interface Configuration

To configure IKEv1 interface parameters:

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

    If DPD has not been enabled, this parameter can be safely ignored.

  6. Use the optional shared-password parameter to assign an interface PSK.

    This IKEv1-interface-specific value over-rides the global default value set at the IKE configuration level.

  7. Use done, exit, and verify-config to complete configuration of IKEv1 interface.
  8. Repeat Steps 1 through 7 to configure additional IKEv1 interfaces.

IKEv1 Security Association Configuration

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

To configure IKEv1 SA parameters:

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

    name enables the creation of multiple ike-sainfo instances.

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

    The following security protocols are available.

    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 14-1 AH Transport Mode

    AH Transport Mode

    Figure 14-2 AH Tunnel Mode

    AH Tunnel Mode

    Figure 14-3 ESP Transport Mode

    ESP Transport Mode

    Figure 14-4 ESP Tunnel Mode

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

    The following authentication protocols are available

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

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

    any (the default) — supports both MD5 and SHA-1. 

    ORACLE(ike-sainfo)# auth-algo md5
ORACLE(ike-sainfo)#
  5. Use the encryption-algo parameter to specify the encryption algorithms supported by this SA.

    The following encryption protocols are available

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

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

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

    any (the default) — supports all listed encryption protocols. 

    ORACLE(ike-sainfo)# encryption-algo aes
ORACLE(ike-sainfo)#
  6. Use the ipsec-mode parameter to specify the IPSec operational mode.

    Transport mode (the default) provides a secure end-to-end connection between two IP hosts. Transport mode encapsulates the IP payload.

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

    Refer to the previous figures for encapsulation details. 

    ORACLE(ike-sainfo)# ipsec-mode tunnel
ORACLE(ike-sainfo)#
  7. If ipsec-mode is tunnel, use the required tunnel-local-addr parameter to specify the IP address of the local IKEv1 interface that terminates the IPsec tunnel.

    This parameter can safely be ignored if ipsec-mode is transport. 

    ORACLE(ike-sainfo)# tunnel-local-addr 192.169.204.14
ORACLE(ike-sainfo)#
  8. If ipsec-mode is tunnel, use the tunnel-remote-addr parameter to specify the IP address of the remote IKEv1 peer that terminates the IPsec tunnel.

    Provide the remote IP address, or use the default wild-card value (*) to match all IP addresses.

    This parameter can safely be ignored if ipsec-mode is transport. 

    ORACLE(ike-sainfo)# tunnel-remote-addr *
ORACLE(ike-sainfo)#
  9. Use done, exit, and verify-config to complete configuration of IKEv1 SA.
  10. Repeat Steps 1 through 9 to configure additional IKEv1 SAs.

IPsec Security Policy Configuration

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

  1. From superuser mode, use the following command sequence to access ike-config configuration mode. While in this mode, you configure global IKEv1 configuration parameters. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ipsec
ORACLE(ipsec)# security-policy
ORACLE(security-policy)#
  2. Use the required ike-sainfo-name parameter to assign an IKv1 SA to this IPsec Security Policy.
  3. Use done, exit, and verify-config to complete configuration of IPsec Security Policy.

Secure Real-Time Transport Protocol

The Secure Real-Time Transport Protocol, as described in RFC 3711, The Secure Real-time Transport Protocol (SRTP), provides a framework for the encryption and authentication of Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) streams. Both RTP and RTCP are defined by RFC 3550, RTP: A Transport Protocol for Real-Time Applications.

Encryption ensures that the call content and associated signaling remains private during transmission. Authentication ensures that (1) received packets are from the purported source, (2) packets are not been tampered with during transmission, and (3) a packet has not been replayed by a malicious server.

Protocol Overview

While the RFC 3711 framework provides encryption and authentication procedures and defines a set of default cryptographic transforms required for RFC compliance, it does not specify a key management protocol to securely derive and exchange cryptographic keys. RFC4568, Session Description Protocol (SDP) Security Description for Media Streams, defines such a protocol specifically designed to exchange cryptographic material using a newly defined SDP crypto attribute. Cryptographic parameters are established with only a single message or in single round-trip exchange using the offer/answer model defined in RFC 3264, An Offer/Answer Model with the Session Description Protocol.

Release S-C6.2.0 provides support for an initial SDP Security Descriptions (SDES) implementation that generates keys used to encrypt SRTP/SRTCP packets. Authentication of packets will be added to a subsequent release.

A sample SDP exchange is shown below:

The SDP offerer sends: 

v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4

The SDP answerer replies: 

v=0
o=sam 2890844526 2890842807 IN IP4 10.47.16.5
s=SRTP Discussion
i=A discussion of Secure RTP
u=http://www.example.com/seminars/srtp.pdf
e=marge@example.com (Marge Simpson)
c=IN IP4 168.2.17.12
t=2873397496 2873404696
m=audio 49170 RTP/SAVP 0
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:WVNfX19zZW1jdGwgKCkgewkyMjA7fQp9CnVubGVz|2^20|1:4

The media-level SDP attribute, crypto, describes the cryptographic suite, key parameters, and session parameters for the preceding unicast media line. The crypto attribute takes the form:

a=crypto: tag crypto-suite key-parameter [session-parameters]

tag

The tag field contains a decimal number that identifies a specific attribute instance. When an offer contains multiple crypto attributes, the answer uses the tag value to identify the accepted offer.

In the sample offer the tag value is 1.

crypto-suite

The crypto-suite field contains the encryption and authentication algorithms, either AES_CM_128_HMAC_SHA1_80 orAES_CM_128_HMAC_SHA1_32.

The key-parameter field contains one or more sets of keying material for the selected crypto-suite and it has following format. 

"inline:" <key||salt> ["|" lifetime] ["|" MKI ":" length]

inline is a method and specifies that the crypto material to be used by the offerer is transmitted via the SDP.

The key||salt field contains a base64-encoded concatenated master key and salt.

Assuming the offer is accepted, the key || salt provides the crypto material used by the offerer to encrypt SRTP/SRTCP packets, and used by the answerer to decrypt SRTP/SRTCP packets.

Conversely the key || salt contained in the answer to the offer provides the crypto material used by the answerer to encrypt SRTP/SRTCP packets, and used by the offerer to decrypt SRTP/SRTCP packets.

The lifetime field optionally contains the master key lifetime (maximum number of SRTP or SRTCP packets encoded using this master key).

In the sample offer the lifetime value is 1,048, 576 (220) packets.

The MKI:length field optionally contains the Master Key Index (MKI) value and the MKI length.

The MKI is used only when the offer contains multiple keys; it provides a means to differentiate one key from another. The MKI takes the form of an integer, followed by its byte length when included in SRTP/SRTCP packets.

In the sample offer the MKI value is 1 with a length of 4 bytes.

The session-parameters field contains a set of optional parameters that may override SRTP session defaults for the SRTP and SRTCP streams.

UNENCRYPTED_SRTP — SRTP messages are not encrypted

UNENCRYPTED_SRTCP — SRTCP messages are not encrypted

UNAUTHENTICATED_SRTP — SRTP messages are not authenticated

When generating an initial offer, the offerer must ensure that there is at least one crypto attribute for each media stream for which security is desired. Each crypto attribute for a given media stream must contain a unique tag. The ordering of multiple crypto attributes is significant — the most preferred crypto suite is listed first.

Upon receiving the initial offer, the answerer must either accept one of the offered crypto attributes, or reject the offer in its entirety.

When an offered crypto attribute is accepted, the crypto attribute in the answer MUST contain the tag and crypto-suite from the accepted crypto attribute in the offer, and the key(s) the answerer will be using for media sent to the offerer.

The crypto-suite is bidirectional and specifies encryption and authentication algorithms for both ends of the connection. The keys are unidirectional in that one key or key set encrypts and decrypts traffic originated by the offerer, while the other key or key set encrypts and decrypts traffic originated by the answerer. The use of symmetric keying, where the same key is used for both encryption and decryption, mandates the key exchange between the offerer and the answerer.

Key exchange via text-based SDP is unacceptable in that malicious network elements could easily eavesdrop and obtain the plaintext keys, thus compromising the privacy and integrity of the encrypted media stream. Consequently, the SDP exchange must be protected by a security protocol such as IPsec or TLS.

Licensing and Hardware Requirements

SRTP/SRTCP support requires the presence of an IPsec NIU and an SSM (Security Service Module).

No additional licences are required.

Operational Modes

SRTP topologies can be reduced to three basic topologies which are described in the following sections.

Single-Ended SRTP Termination

Single-ended SRTP termination is illustrated in the following figure.

The Single-Ended SRTP Termination diagram is described below.

Single-Ended SRTP Termination

If SRTP is enabled for the inbound realm/interface, the Oracle Communications Session Border Controller handles the incoming call as specified by the Media Security Policy assigned to the inbound realm. If there is crypto attribute contained in the offer, the Oracle Communications Session Border Controller parses the crypto attributes and optional parameters, if any. If the offer contains a crypto attribute or attributes compatible with the requirements specified by the SDES profile assigned to the Media Security policy, it selects the most preferred compatible attribute. Otherwise, the Oracle Communications Session Border Controller rejects the offer. Before the SDP is forwarded to the called party, the Oracle Communications Session Border Controller allocates resources, established SRTP and SRTCP Security Associations and updates the SDP by removing the crypto attribute and inserting possibly NAT’ed media addresses and ports. At the same time, the original crypto attribute is also removed from the SDP.

Once the reply from the called party is received, the Oracle Communications Session Border Controller inserts appropriate crypto attribute(s) to form a new SDP, and forward the response back to the calling party.

Back-to-Back SRTP Termination

Back-to-back SRTP termination is illustrated in the following figure.

The Back-to-Back SRTP Termination diagram is described below.

Back-to-Back SRTP Termination

Initial processing is similar to the single-ended termination described above. Before forwarding the request to the called party, the Oracle Communications Session Border Controller replaces the original crypto attribute with a new one whose crypto attribute conforms to the media security policy for the outbound realm/interface. Upon receiving the answer from the called party, the Oracle Communications Session Border Controller accepts or rejects it, again based upon conformity to the media security policy. If accepted, the Oracle Communications Session Border Controller replaces the original crypto attribute from the called party with its own to form a new SDP, which it forwards back to the calling party. At this point, SRTP media sessions are established on both sides for both calling and called parties.

SRTP Pass-Thru

SRTP pass-thru is illustrated in the following figure.

The SRTP Pass-Thru diagram is described below.

SRTP Pass-Thru

If the media security policy specifies pass-through mode, the Oracle Communications Session Border Controller does not alter the crypto attribute exchange between the calling and the called party; the attribute is transparently passed.

SDES Configuration

SDES configuration consists of the following steps.

  1. Create one or more SDES profiles which specify parameter values negotiated during the offer/answer exchange.
  2. Create one or more Media Security Policies that specify key exchange protocols and protocol-specific profiles.
  3. Assign a Media Security Policy to a realm.
  4. Create an interface-specific Security Policy.

SDES Profile Configuration

An SDES profile specifies the parameter values offered or accepted during SDES negotiation.

To configure SDES profile parameters:

  1. From superuser mode, use the following command sequence to access sdes-profile configuration mode. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# media-security
ORACLE(media-security)# sdes-profile
ORACLE(sdes-profile)#
  2. Use the required name parameter to provide a unique identifier for this sdes-profile instance.

    name enables the creation of multiple sdes-profile instances.

  3. Use the crypto-suite parameter to select the encryption and authentication algorithms accepted or offered by this sdes-profile.

    Allowable values are:

    AES_CM_128_HMAC_SHA1_80 (the default value)

    supports AES/128 bit key for encryption and HMAC/SHA-1 80-bit digest for authentication

    AES_CM_128_HMAC_SHA1_32

    supports AES/128 bit key for encryption and HMAC/SHA-1 32-bit digest for authentication

  4. Because SRTP authentication is not currently supported, ignore the srtp-auth parameter.
  5. Use the srtp-encrypt parameter to enable or disable the encryption of RTP packets.

    With encryption enabled, the default condition, the Oracle Communications Session Border Controller offers RTP encryption, and rejects an answer that contains an UNENCRYPTED_SRTP session parameter in the crypto attribute.

    With encryption disabled, the Oracle Communications Session Border Controller does not offer RTP encryption and includes an UNENCRYPTED_SRTP session parameter in the SDP crypto attribute; it accepts an answer that contains an UNENCRYPTED_SRTP session parameter.

  6. Use the srtcp-encrypt parameter to enable or disable the encryption of RTCP packets.

    With encryption enabled, the default condition, the Oracle Communications Session Border Controller offers RTCP encryption, and rejects an answer that contains an UNENCRYPTED_SRTCP session parameter in the crypto attribute.

    With encryption disabled, the Oracle Communications Session Border Controller does not offer RTCP encryption and includes an UNENCRYPTED_SRTCP session parameter in the SDP crypto attribute; it accepts an answer that contains an UNENCRYPTED_SRTCP session parameter.

  7. Use the mki parameter to enable or disable the inclusion of the MKI:length field in the SDP crypto attribute.

    The master key identifier (MKI) is an optional field within the SDP crypto attribute that differentiates one key from another. MKI is expressed as a pair of decimal numbers in the form: |mki:mki_length| where mki is the MKI integer value and mki_length is the length of the MKI field in bytes. For hardware-based platforms, the length value can be up to 32 bytes. For software-based platforms, the length value is 4 bytes.

    The MKI field is necessary only in topologies that may offer multiple keys within the crypto attribute.

    Allowable values are enabled and disabled (the default).

    enabled – an MKI field is sent within the crypto attribute (16 bytes maximum)

    disabled – no MKI field is sent

  8. Use done, exit, and verify-config to complete configuration of this SDES profile instance.
  9. Repeat Steps 1 through 8 to configure additional SDES profiles.

Media Security Policy Configuration

Use the following procedure to create a Media Security Policy that specifies the role of the Oracle Communications Session Border Controller in the security negotiation. If the Oracle Communications Session Border Controller takes part in the negotiation, the policy specifies a key exchange protocol and SDES profile for both incoming and outgoing calls.

Note:

The media security policy configuration does not apply to hairpin calls.

To configure media-security-policy parameters:

  1. From superuser mode, use the following command sequence to access media-sec-policy configuration mode. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# media-security
ORACLE(media-security)# media-sec-policy
ORACLE(media-sec-policy)#
  2. Use the required name parameter to provide a unique identifier for this media-sec-policy instance.

    name enables the creation of multiple media-sec-policy instances.

  3. Use optional pass-thru parameter to enable or disable pass-thru mode.

    With pass-thru mode enabled, the User Agent (UA) endpoints negotiate security parameters between each other; consequently, the Oracle Communications Session Border Controller simply passes SRTP traffic between the two endpoints.

    With pass-thru mode disabled (the default state), the Oracle Communications Session Border Controller disallows end-to-end negotiation — rather the Oracle Communications Session Border Controller initiates and terminates SRTP tunnels with both endpoints.

  4. Use the outbound navigation command to move to media-sec-outbound configuration mode. While in this configuration mode you specify security parameters applied to the outbound call leg, that is calls sent by the Oracle Communications Session Border Controller.
  5. Use the protocol parameter to select the key exchange protocol.

    Select sdes for SDES key exchange.

  6. Use the profile parameter to specify the name of the SDES profile applied to calls sent by the Oracle Communications Session Border Controller.
  7. Use the mode parameter to select the real time transport protocol.

    Allowable values are rtp and srtp (the default).

    mode identifies the transport protocol (RTP or SRTP) included in an SDP offer when this media-security-policy is in effect.

  8. Use the done and exit parameters to return to media-sec-policy configuration mode.
  9. Use the inbound navigation command to move to media-sec-inbound configuration mode. While in this configuration mode you specify security parameters applied to the inbound call leg, that is calls received by the Oracle Communications Session Border Controller.
  10. Use the protocol parameter to select the key exchange protocol.

    Select sdes for SDES.

  11. Use the profile parameter to specify the name of the SDES profile applied to calls received by the Oracle Communications Session Border Controller.
  12. Use the mode parameter to select the real time transport protocol.

    Allowable values are rtp and srtp (the default).

    mode identifies the transport protocol (RTP or SRTP) accepted in an SDP offer when this media-security-policy is in effect.

  13. Use done, exit, and verify-config to complete configuration of this media security policy instance.
  14. Repeat Steps 1 through 13 to configure additional media-security policies.

Assign the Media Security Policy to a Realm

To assign a media-security-policy to a realm:

  1. From superuser mode, use the following command sequence to access realm-config configuration mode. While in this mode, you assign an existing media-security-policy to an existing realm. 
    ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# realm-config
ORACLE(realm-config)# select
identifier:
1. access-12
...
...
selection: 1
ORACLE(realm-config)#
  2. Use the media-sec-policy parameter to assign the policy to the target realm.
  3. Use done, exit, and verify-config to complete assignment of the media-security-policy to the realm.

ACLI Example Configurations

The following section contain relevant sections of system configurations for basic operational modes.

Single-Ended SRTP Termination Configuration

ORACLE# show running-config
...
...
...
sdes-profile
    name                       sdes1
    crypto-list                AES_CM_128_HMAC_SHA1_80
    srtp-auth                  enabled
    srtp-encrypt               enabled
    srtcp-encrypt              enabled
    mki                        disabled
    key
    salt
    last-modified-by           admin@console
    last-modified-date         2009-11-16 15:37:13
media-sec-policy
    name                       msp2
    pass-through               disabled
    inbound
        profile                sdes1
        mode                   srtp
        protocol               sdes
    outbound
        profile                sdes1
        mode                   srtp
        protocol               sdes
    last-modified-by           admin@console
    last-modified-date         2009-11-16 15:37:51
...
...
...
realm-config
    identifier                 peer
    description
    addr-prefix                192.168.0.0/16
    network-interfaces         M00:0
    mm-in-realm                enabled
    mm-in-network              enabled
    mm-same-ip                 enabled
    mm-in-system               enabled
    bw-cac-non-mm              disabled
    msm-release                disabled
    qos-enable                 disabled
    generate-UDP-checksum      disabled
    max-bandwidth              0
    fallback-bandwidth         0
    max-priority-bandwidth     0
    max-latency                0
    max-jitter                 0
    max-packet-loss            0
    observ-window-size         0
    parent-realm
    dns-realm
    media-policy
    media-sec-policy           msp2
    in-translationid
...
...
...
    last-modified-by          admin@console
    last-modified-date        2009-11-10 15:38:19

Back-to-Back SRTP Termination Configuration

ORACLE# show running-config
...
...
...
sdes-profile
   name                       sdes1
   crypto-list                AES_CM_128_HMAC_SHA1_80
   srtp-auth                  enabled
   srtp-encrypt               enabled
   srtcp-encrypt              enabled
   mki                        disabled
   key
   salt
   last-modified-by           admin@console
   last-modified-date         2009-11-16 15:37:13
media-sec-policy
   name                       msp2
   pass-through               disabled
   inbound
      profile                 sdes1
      mode                    srtp
      protocol                sdes
   outbound
      profile                 sdes1
      mode                    srtp
      protocol	               sdes
   last-modified-by           admin@console
   last-modified-date         2009-11-16 15:37:51
...
...
...
realm-config
   identifier                 peer
   description
   addr-prefix                192.168.0.0/16
   network-interfaces         M00:0
   mm-in-realm                enabled
   mm-in-network              enabled
mm-same-ip                    enabled
   mm-in-system               enabled
   bw-cac-non-mm              disabled
   msm-release                disabled
   qos-enable                 disabled
   generate-UDP-checksum      disabled
   max-bandwidth              0
   fallback-bandwidth         0
   max-priority-bandwidth     0
   max-latency                0
   max-jitter                 0
   max-packet-loss            0
   observ-window-size         0
   parent-realm
   dns-realm
   media-policy
   media-sec-policy	msp2
...
...
...
realm-config
   identifier                 core
   description
   addr-prefix                172.16.0.0/16
   network-interfaces         M10:0
   mm-in-realm                enabled
   mm-in-network              enabled
   mm-same-ip                 enabled
   mm-in-system               enabled
   bw-cac-non-mm              disabled
   msm-release                disabled
   qos-enable                 disabled
   generate-UDP-checksum      disabled
   max-bandwidth              0
   fallback-bandwidth         0
   max-priority-bandwidth     0
   max-latency                0
   max-jitter                 0
   max-packet-loss            0
   observ-window-size         0
   parent-realm
   dns-realm
   media-policy
   media-sec-policy           msp2
   in-translationid
...
...
...
   last-modified-by           admin@console
   last-modified-date         2009-11-10 15:38:19

SRTP Pass-Thru Configuration

ORACLE# show running-config
...
...
...
sdes-profile
   name                            sdes1
   crypto-list                     AES_CM_128_HMAC_SHA1_80
   srtp-auth                       enabled
   srtp-encrypt                    enabled
   srtcp-encrypt                   enabled
   mki                             disabled
   key
   salt
   last-modified-by                admin@console
   last-modified-date              2009-11-16 15:37:13
media-sec-policy
   name                            msp2
   pass-through                    enabled
   inbound
      profile                      sdes1
      mode                         srtp
      protocol                     sdes
   outbound
      profile                      sdes1
      mode                         srtp
      protocol                     sdes
   last-modified-by                admin@console
   last-modified-date              2009-11-16 15:37:51
...
...
...
realm-config
   identifier                     	peer
   description
   addr-prefix                    	192.168.0.0/16
   network-interfaces              M00:0
   mm-in-realm                    	enabled
   mm-in-network                  	enabled
   mm-same-ip                     	enabled
   mm-in-system                   	enabled
   bw-cac-non-mm                  	disabled
   msm-release                    	disabled
   qos-enable                     	disabled
   generate-UDP-checksum          	disabled
   max-bandwidth                  	0
   fallback-bandwidth             	0
   max-priority-bandwidth         	0
   max-latency                    	0
   max-jitter                     	0
   max-packet-loss                	0
   observ-window-size             	0
   parent-realm
   dns-realm
   media-policy
   media-sec-policy                 msp2
...
...
...
realm-config
   identifier                     	core
   description
   addr-prefix                    	172.16.0.0/16
   network-interfaces              M10:0
   mm-in-realm                    	enabled
   mm-in-network                  	enabled
   mm-same-ip                     	enabled
   mm-in-system                   	enabled
   bw-cac-non-mm                  	disabled
   msm-release                    	disabled
   qos-enable                     	disabled
   generate-UDP-checksum          	disabled
   max-bandwidth                  	0
   fallback-bandwidth             	0
   max-priority-bandwidth         	0
   max-latency                    	0
   max-jitter                     	0
   max-packet-loss                	0
   observ-window-size             	0
   parent-realm
   dns-realm
   media-policy
   media-sec-policy                 msp2
   in-translationid
   ...
   ...
   ...
   last-modified-by                 admin@console
   last-modified-date               2009-11-10 15:38:19

Security Policy

A Security Policy enables the Oracle Communications Session Border Controller to identify inbound and outbound media streams that are treated as SRTP/SRTCP. The high-priority Security Policy, p1, (shown below) allows signaling traffic from source 172.16.1.3 to destination 172.16.1.10:5060. The lower-priority Security Policy, p2, (also shown below) matches media traffic with the same source and destination, but without any specific ports. Consequently, SIP signaling traffic (from local port 5060) go through, but the media stream will be handled by appropriate SRTP SA. 

security-policy
     name                              p1
     network-interface                 private:0
     priority                          0
     local-ip-addr-match               172.16.1.3
     remote-ip-addr-match              172.16.1.10
     local-port-match                  5060
     remote-port-match                 0
     trans-protocol-match              UDP
     direction                         both
     local-ip-mask                     255.255.255.255
     remote-ip-mask                    255.255.255.255
     action                            allow
     ike-sainfo-name
     outbound-sa-fine-grained-mask
          local-ip-mask                255.255.255.255
          remote-ip-mask               255.255.255.255
          local-port-mask              0
          remote-port-mask             0
          trans-protocol-mask          0
          valid                        enabled
          vlan-mask                    0xFFF
     last-modified-by                  admin@console
     last-modified-date                2009-11-09 15:01:55

security-policy
     name                              p2
     network-interface                 private:0
     priority                          10
     local-ip-addr-match               172.16.1.3
     remote-ip-addr-match              172.16.1.10
     local-port-match                  0
     remote-port-match                 0
     trans-protocol-match              UDP
     direction                         both
     local-ip-mask                     255.255.255.255
     remote-ip-mask                    255.255.255.255
     action                            ipsec
     ike-sainfo-name
     outbound-sa-fine-grained-mask
          local-ip-mask                0.0.0.0
          remote-ip-mask               255.255.255.255
          local-port-mask              0
          remote-port-mask             65535
          trans-protocol-mask          255
          valid                        enabled
          vlan-mask                    0xFFF
     last-modified-by                  admin@console
     last-modified-date                2009-11-09 15:38:19

Modified ALCI Configuration Elements

The action parameter in security-policy configuration mode has been modified to accept additional values, srtp and srtcp.

  1. From superuser mode, use the following command sequence to access media-sec-policy configuration mode. 
    ORACLE# configure terminal
ORACLE(configure)# security
ORACLE(security)# ipsec
ORACLE(ipsec)# security-policy
ORACLE(security-policy)# action ?
<enumeration> action (default: ipsec)
ipsec, allow, discard, srtp, srtcp
ORACLE(security-policy)#

    The show security command has been updated with an srtp option. 

    ORACLE# show security srtp
sad
spd
statistics
SRTP Statistics
status

    The srtp option is similar to the ipsec option save for the sad sub-option that provides data for only SRTP SAs.

    The show sa stats command has been updated with an srtp option. 

    ORACLE# show sa stats
<ENTER>	Show statistics summary of all Security Associations
<ike>	Show statistics for IKE Security Associations
<ims-aka>	Show statistics for IMS-AKA Security Associations
<srtp>	Show statistics for SRTP Security Associations
sd# show sa stats srtp
20:06:24-114
SA Statistics                   ---- Lifetime ----
                           Recent   Total   PerMax
SRTP Statistics
ADD-SA Req Rcvd              0        0        0
ADD-SA Success Resp Sent     0        0        0
ADD-SA Fail Resp Sent        0        0        0
DEL-SA Req Rcvd              0        0        0
DEL-SA Success Resp Sent     0        0        0
DEL-SA Fail Resp Sent        0        0        0
SA Added                     0        0        0
SA Add Failed                0        0        0
SA Deleted                   0        0        0
SA Delete Failed             0        0        0