SBCs are network elements that are deployed at the border between packet-based
networks to manage the signaling and media messages that support Internet
multimedia services (for example, voice or video). For example, they can
be placed between service providers in a peering configuration or in an
access network that provides VoIP service to residential or enterprise
customers. SBCs are considered network border elements that enforce security
and service policies. Figure 8.10 depicts the placement of the SBC in
an IP network.
FIGURE 8.10: SBC network placement
When Bob makes a call to Alice (from domain A to domain B), the signaling
messages generated from Bob's phone that are sent to the local SIP proxy
(or H.323 gatekeeper in case H.323 is used) traverse domain A's SBC and
then domain B's SBC, which in turn will contact Alice's SIP proxy. Finally,
Alice's SIP proxy will signal her phone to alert her that Bob would like
to initiate a session. When Alice picks up the phone, a SIP response is
generated and traverses the intermediate SIP proxies and SBCs (Alice's
SIP proxy, SBC domain B to SBC domain A, and finally Bob's SIP proxy)
until it reaches Bob's phone. When the signaling to set up the session
is complete, the two end points start transmitting voice using the RTP
protocol. Note that although the signaling messages traverse the SBCs
and the intermediate SIP proxies, the media packets traverse only the
SBCs but not the proxies. This allows the SBCs to control signaling and
media messages and provides the ability to enforce policies to protect
against associated attacks (for example, malicious messages and bandwidth-consuming
attacks to disrupt or degrade service).
The remote components (for example, phones or proxies) interact with
the SBC as if it were the other remote end and not an intermediary, and
therefore the SBC is labeled a back-to-back user agent (B2BUA). Figure
8.11 depicts this configuration.
FIGURE 8.11: A logical representation of an SBC (B2BUA)
When the SBC receives an incoming request to set up a call (for example,
INVITE), it acts as if it were the end point (for example, Alice's phone)
and sends a provisional response (for example, 100 Trying) to the caller
(for example, Bob's phone) to indicate that the dialogue is in progress.
At the same time, the SBC initiates a new request to contact the callee
(for example, Alice). When the SBC receives a response from the callee,
it forwards it to the caller. Figure 8.12 depicts the call flow in which
an SBC is terminating and reinitiating signaling messages.
The SBC also terminates the incoming RTP stream and initiates a new
RTP stream to the remote end. This ability allows managing the media format
(for example, CODEC) that is used in a session to modify the RTP stream
as needed. This is called transcoding, in which a network element encodes
an RTP stream from one format to another (for example, from Pulse Code
Modulation u-law PCMU to G.726). The same functionality is also available
for signaling (for example, SIP-to-H.323 translation).
FIGURE 8.12: SBC call flow example
The ability of the SBC to manage multimedia sessions provides the means
to enforce various controls to support security objectives. 3
The controls that can be used by an SBC to protect against attacks include
the following:
Traffic rate limiting—This functionality
provides the ability to control the number of simultaneous sessions
(calls) from a given source, which can be a collection of devices or
a distinct device caller. In addition, this control helps prevent from
occupying PSTN links of backend components. This helps mitigate against
DoS attacks, including DDoS (distributed DoS), that aim to impact or
disrupt service availability. Rate limiting can also be enforced by
inline deep packet inspection devices and can be detected by passive
deep packet inspection devices or intrusion detection sensors.
Message inspection—The SBC can
inspect the syntax and format of signaling and media messages to protect
against attacks that use malformed messages (for example, DoS, buffer
overflow).
Network topology hiding—An SBC
provides the ability to hide the configuration of network elements that
reside behind it using NAT (Network Address Translation). The ability
to hide the network addressing scheme that is used by internal components
provides a layer of protection from attacks that require direct interaction
with the target.
Session management—In addition
to providing QoS for sessions, the SBC can enforce controls to support
security, including the following:
—Access control. Because the SBC can manage the signaling
and media streams dynamically, it can control traffic flow based
on IP, SIP URI, and other properties (for example, RTP ports). Furthermore,
it can provide authentication of signaling messages at the network
and application layers to enforce call/session admission.
—NAT traversal. Provides network topology hiding and
message modifications to overcome issues with private IP addresses
(RFC 1918) in signaling messages (for example, SIP/SDP).
—Modification and termination of sessions. The SBC
can modify the state and parameters of a multimedia session, including
parameters in the signaling and media stream (for example, SIP/H.323,
SDP, RTP), to enforce a policy. For example, a policy may dictate
that sessions that originate from specific networks are not admitted
or they should be redirected to another SBC that serves a corresponding
geographic region. Or another policy would be to discard and log
any calls that are made between 12 a.m. and 8 a.m.
—UDP stream management. Dynamic allocation and management
of UDP ports to protect from unsolicited UDP traffic and attacks
(for example, DoS, SPIT, UDP injection). In addition, the SBC may
perform transcoding of media packets to meet certain audio/visual
requirements. This allows the SBC to inspect the RTP traffic and
detect and discard any malicious or erroneous packets. The SBC can
detect whether end points have properly completed the exchange of
signaling messages before sending RTP traffic and reflect more accurate
information for billing (see the related discussion about fraud
in Chapter 3). Also, in a scenario in which a calling card is used,
the SBC can terminate a call if the user runs out of available minutes.
In addition, SBCs tend to be ideal components to enforce lawful intercept
because they are in the communication path of participants and control
both the signaling and media stream. At the same time, this opportunity
increases the security requirements for SBCs when it comes to management
and administration, especially if the SBC is deployed to manage traffic
originating from the Internet, which increases the threat level and number
of attacks that can be performed. Imagine the consequences to the network
operator and law enforcement agency if an SBC is compromised while executing
a surveillance warrant.
These controls are defined in the SBC's security policy, which organizes
and enforces operational, organizational, and service requirements. For
example, a policy may dictate that sessions that originate from specific
networks are not admitted or they should be redirected to another SBC
that serves a corresponding geographic region. These functions may be
found in the IMS architecture distributed across various components, such
as P-CSCF (Proxy-call/Session Control Function), I-CSCF (Interrogating-Call/Session
Control Function), or a SEG (Security Gateway).
Limitations of SBCs
Every good story comes to an end. Although SBCs provide several features
to protect from various attacks, they also get in the way of supporting
certain security functions and objectives. The limitations associated
with security include the following:
Confidentiality and end-to-end privacy is hampered—SBCs intercept
signaling and media traffic to make decisions based on the enforced
policy. If the SBC receives an encrypted signaling or media packet,
it will have to decrypt the incoming packet to process it, and therefore
it must maintain a set of cryptographic keys associated with the corresponding
session. So, the SBC will have to decrypt, process, and re-encrypt the
packets if necessary to maintain confidentiality on the other end. This
procedure limits end-to-end confidentiality because the SBC acts as
man in the middle, and encryption parameters do not remain consistent
(for example, digital signatures).
Authentication—Verifying user and device identity is important
in Internet multimedia applications, including VoIP. Features such as
caller ID are used by businesses to identify customers. If caller ID
information can be spoofed in a call, it can be used to perform a number
of attacks. For example, a well-known international cellular carrier
performs voice mailbox authentication using caller ID. An attacker can
use this weakness to spoof the caller ID and manage, modify, retrieve,
or delete messages on subscriber mailboxes. There are currently VoIP
service providers which offer service to residential and enterprise
customers that may not enforce proper message authentication controls.
For example, a service provider may deploy security components such
as an SBC the products do provide the ability to validate a subscriber's
identity and thus allowing attacks such as Caller-ID spoofing.
Proprietary extension support—As vendors strive to maintain
competitiveness, they will introduce features and extensions to the
protocols used for VoIP (for example, SIP, SDP, RTP). In some cases,
vendor extensions might not be supported by the SBC, and thus might
limit the ability to extend services or enforce security policies (for
example, a proprietary authentication mechanism, message inspection).
Reliability of session state—One of the fundamental functions
of the SBC is maintaining session state. If the SBC operation is disrupted
(for example, hardware/software malfunction or attack), all session
state information is lost, and it will cease processing packets from
sessions that were established prior to the outage. For example, if
the SBC removes Via entries from a request and then restarts, losing
state, the SBC will not be able to route responses to that request.
It is advisable to maintain a redundant SBC configuration to overcome
service unavailability introduced by the use of a single SBC in case
of a failure.
Footnote
3. J. Hautakopi, et al. Requirements from
SIP (Session Initiation Protocol) Session Border Control Deployments,
IETF draft-camarillo-sipping-sbc-funcs-04.txt.
Reproduced from the book Securing VoIP Networks, Addison Wesley,
Copyright 2008, Pearson Education, Inc.
Reproduced by permission.
Visit www.aw-bc.com
for a detailed description and to learn how to purchase this title.
This excerpt first appeared on our sister website, ISP-Planet.com.
IE 7
Firefox 2.0