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
Signaling address: 10.1.0.2:5060
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
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
|