Cisco IOS XR Session Border Controller Configuration Guide Release 3.6
Encrypted SIP Signaling

Table Of Contents

Encrypted SIP Signaling

Contents

Prerequisites for Implementing Encrypted SIP Signaling

Restrictions for Implementing Encrypted SIP Signaling

Information About Encrypted SIP Signaling

Security Configuration on an Adjacency

User Agent Server (UAS) Side Processing

Routing Processing

User Agent Client (UAC) Side Processing

How to Configure Encrypted SIP Signaling

Configuring Encrypted SIP Signaling

Example of a Show Command Displaying the Level of Security Configured for Adjacencies

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance


Encrypted SIP Signaling


Encrypted SIP signaling provides a secure, encrypted transport to carry all SIP messages from the caller to the callee's domain. From there, the request is sent securely to the callee. The SBC provides the following support for the encrypted SIP signaling:

Secured SIP calls can flow through the SBC.

A SIP adjacency may be configured as unsecured, secured due to non-encryption-related mechanisms (for example, a single trusted physical-layer link or an interface to a trusted network), or secured by encryption.

Inbound and outbound connections are immediately closed if a remote peer attempts to use encryption when encryption is not supported.

Inbound and outbound connections are immediately closed if a remote peer fails to use encryption when encryption is required.

You can view the level of security support configured for a given SIP adjacency by using the relevant show command.

Calls received on untrusted adjacencies may not be routed over outbound secure-encrypted adjacencies.

Adjacencies secured by means of encryption listen by default on port 5061. The port may be configured to a different value.

The fully-qualified domain name (FQDN) in the certificate offered by the remote peer is checked against the domain from which the request is received. The signal is dropped if the two do not match.

Feature History for Encrypted SIP Signaling

Release
Modification

Release 3.4.1

This feature was introduced on the Cisco XR 12000 Series Router.

Release 3.5.0

No modification.

Release 3.6.0

No modification.


Contents

This module contains the following sections:

Prerequisites for Implementing Encrypted SIP Signaling

Restrictions for Implementing Encrypted SIP Signaling

Information About Encrypted SIP Signaling

How to Configure Encrypted SIP Signaling

Example of a Show Command Displaying the Level of Security Configured for Adjacencies

Additional References

Prerequisites for Implementing Encrypted SIP Signaling

The following prerequisites are required for implementing encrypted SIP signaling:

Security Package is required for the encrypted SIP signaling feature.

Store certificates are generated by CEPKI infrastructure.

Restrictions for Implementing Encrypted SIP Signaling

The following restriction apply to encrypted SIP signaling:

Security policy cannot be changed on a SIP adjacency while the adjacency is attached.

The only encryption support required by SBC is Secure Sockets Layer (SSL) over Transport Layer Security (TLS). IPSec and SCTP encryptions are not supported.

For SIP TLS calls, it is necessary to install the k9sec.pie, then configure a router certificate before configuring the SBC. If this process is not followed, the SBC rejects TLS calls.

The SBC is not required to generate, store, or maintain certificates. This function is performed by the CEPKI infrastructure.

Encrypted adjacencies do not accept unencrypted traffic.

Unencrypted adjacencies do not accept encrypted traffic.

The SBC does not redirect secure requests to insecure targets or vice-versa as a result of 3xx redirection or target-refresh. For example, a call directed to a SIPS Uniform Resource Identifier (URI) cannot be redirected to a SIP URI. If this is attempted, the call is brought down by means of the negative INVITE response or by sending BYEs to both parties.

Endpoints are not permitted to register a SIPS address-of-record unless they also provide a SIPS contact address.

Calls are not permitted from unsecured adjacencies to secured adjacencies.

The SBC does not protect against trusted network elements downgrading the security of a call. If an outbound call is sent over a secure adjacency to a proxy, which redirects the call to an insecure target and then returns the call to the SBC, the SBC may forward the call to the new target out of the untrusted adjacency. Since the SBC has a secure connection with the proxy, it trusts the proxy's routing decisions. The two call legs in this example appear as different calls to the SBC, therefore, the SBC does not know that the inbound call leg was secured.

Information About Encrypted SIP Signaling

The two main security factors that are used in routing or rejecting a call are

Calls to a SIPS URI have to be secure. Calls to a SIP URI don't have to be secure.

Signals received on a trusted adjacency are considered secure. Signals received on an untrusted adjacency are considered insecure.

Security Configuration on an Adjacency

You may independently configure client and server security support on a SIP adjacency using the following three options:

Untrusted: This adjacency is not secured by any means. Only insecure calls (not the calls to SIPS URIs) may be made out of this adjacency.

Trusted-Encrypted: Encrypted signaling is used to ensure security on this adjacency. The default certificate and key of the router are used for encryption. Only secure calls (calls to SIPS URIs) may be made out of this adjacency.

Trusted-Unencrypted: A mechanism outside SIP is used to guarantee secure signaling for all messages on this adjacency. For example, this mechanism can be a single trusted physical link. Either secure or insecure calls are made out of this adjacency. This configuration allows endpoints that do not support encryption to participate in secure SIP calls.

User Agent Server (UAS) Side Processing

Inbound requests are marked according to two factors: whether the caller is trusted, and whether the call is intended for a secure target.

The caller-trust is determined in the following way:

SIP requests arriving over trusted adjacencies are marked as trusted.

SIP requests arriving over untrusted adjacencies are marked as untrusted.

Desired target security is determined in the following way:

Requests for SIPS URIs are marked to require the outbound-security.

Requests for SIP URIs are marked not to require the outbound-security.

Inbound requests are rejected if the caller is untrusted and the target requires security. All other combinations are forwarded to routing processing.

Routing Processing

The Routing Policy System (RPS) policy determines where the requests are routed next, with the following default behavior:

If a call requires the outbound security, then the RPS considers only the trusted outbound adjacencies.

If a call does not require the outbound security, then the RPS considers only untrusted or trusted-unencrypted outbound adjacencies.

If the RPS is unable to find a suitable outbound adjacency for a call, then the call is rejected.

User Agent Client (UAC) Side Processing

Outbound adjacencies preserve the URI scheme of the original request, ensuring that if a call is originally targeted at a SIPS URI, it is sent out to a SIPS URI. Or, if the call is originally targeted at a SIP URI, it is sent out to a SIP URI.

Upon receipt of 3xx class responses and target-refresh indications, the contact set is examined. Untrusted adjacencies do not permit the target of the call to be rerouted to a SIPS target. Likewise, trusted adjacencies do not permit the target of the call to be rerouted to a SIP target. If this is attempted by the remote peer, then the call is brought down.

How to Configure Encrypted SIP Signaling

This section contains the steps for configuring encrypted SIP signaling.

Configuring Encrypted SIP Signaling

SUMMARY STEPS

1. configure

2. sbc service-name

3. sbe

4. adjacency sip adjacency-name

5. security type

6. commit

7. exit

8. show services sbc service-name sbe adjacencies

DETAILED STEPS

 
Command or Action
Purpose

Step 1 

configure

Example:

RP/0/0/CPU0:router# configure

Enables global configuration mode.

Step 2 

sbc service-name

Example:

RP/0/0/CPU0:router(config)# sbc mysbc

Enters the mode of an SBC service.

Use the service-name argument to define the name of the service.

Step 3 

sbe

Example:

RP/0/0/CPU0:router(config-sbc)# sbe

Enters the mode of the signaling border element (SBE) function of the SBC.

Step 4 

adjacency sip adjacency-name

Example:

RP/0/0/CPU0:router(config-sbc-sbe)# adjacency sip test

Enters the mode of an SBE SIP adjacency.

Use the adjacency-name argument to define the name of the service.

Step 5 

security type

Example:

RP/0/0/CPU:router(config-sbc-sbe-adj-sip)# security trusted-encrypted


Details how transport-level security is implemented on this adjacency. The "no" version of this command indicates that this adjacency cannot be secured. This field can only be changed when the adjacency is detached.

Possible values for type are:

untrusted—The adjacency is not secured.

trusted-encrypted—The adjacency is secured by means of encryption.

trusted-unencrypted—The adjacency is assumed to be secure by other means (for example, a single dedicated physical link).

Step 6 

commit

Example:

RP/0/0/CPU0:router(config-sbc-sbe-adj-sip)# commit

Saves configuration changes. Use the commit command to save the configuration changes to the running configuration file and remain within the configuration session.

Step 7 

exit

Example:

RP/0/0/CPU0:router(config-sbc-sbe-adj-sip)# exit

Exits the SIP mode and returns to the SBE mode. Keep entering the exit command to exit out of the modes.

Step 8 

show services sbc service-name sbe adjacencies

Example:

RP/0/0/CPU0:router# show services sbc mysbc sbe adjacencies

Displays the level of security support configured for all adjacencies.

Example of a Show Command Displaying the Level of Security Configured for Adjacencies

# show services sbc sbe adjacencies
SBC Service "TestSBC"
  Adjacency SipA (SIP)
    Status:              Attached
    Signaling address:   10.1.0.2:5060
    Signaling-peer:      1.2.3.4
    Account:             ISP123
    Security:            Trusted-Encrypted

Additional References

The following sections provide references related to encrypted SIP signaling on the SBC.

Related Documents

Related Topic
Document Title

Cisco IOS XR master command reference

Cisco IOS XR Master Commands List

Cisco IOS XR SBC interface configuration commands

Cisco IOS XR Session Border Controller Command Reference

Initial system bootup and configuration information for a router using the Cisco IOS XR Software

Cisco IOS XR Getting Started Guide

Cisco IOS XR command modes

Cisco IOS XR Command Mode Reference


Standards

Standards
Title

No new or modified standards are supported by this feature, and support from existing standards has not been modified by this feature.


MIBs

MIBs
MIBs Link

To locate and download MIBs using Cisco IOS XR software, use the Cisco MIB Locator found at the following URL and choose a platform under the Cisco Access Products menu:

http://cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml


RFCs

RFCs
Title

RFC 3261

SIP: Session Initiation Protocol

RFC 2543

Session Initiation Protocol


Technical Assistance

Description
Link

The Cisco Technical Support website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content.

http://www.cisco.com/techsupport