Presence and IntComm WG

[Ben Teitelbaum <>]

Nice summary of SBC tradeoffs...

--- Begin Message ---

• From: Christian Schlatter <>
• To: 'Rui Ribeiro' <>
• Cc:
• Subject: Re: [tf-vvc] Deploying VoIP on a WAN
• Date: Mon, 06 Feb 2006 14:25:06 -0500
• Xref: Ben-Teitelbaums-Computer.local mail.inbox:87761

Rui,

'Rui Ribeiro' wrote:
> As many of you may know, we are undertaking several tests in order to test
> the interoperability between several PBX IP from diferent vendors. Until
> now, we were trusting that the VoIP IP PBX were good enough to be
> interconnected direcly, however, one of the vendors have presented the "SBC"
> concept.
>
> The "SBC" (Session Border Controller) is not a new concpet since we were
> using it anyway when we setup a (Asterisk+SER+SIP Proxy) Box to handle the
> "on-net dialout" calls.

What do you mean with "on-net dialout"?

>
> I'm now overwelmed with the amount of SBCs that are sugested by the vendors
> to implement a solution.
> (http://www.juniper.net/solutions/literature/solutionbriefs/351085.pdf)

Since SBCs are not covered by any RTC standards, their functionality is
not clearly defined. The common denominator seems to be that an SBC
implements a B2BUA (back-to-back user agent) so that it has full control
over the signaling as well as the media path of all traversal calls. The
advantages of a B2BUA are

- Near-end firewall traversal: The B2BUA can be placed in the DMZ and
the firewall only allows RTC traffic from/to B2BUA

- Far-end firewall/NAT traversal: A B2BUA can detect private IP
addresses in signaling messages payload and is able to send keep-alive
messages to endpoints in order to keep statefull FWs/NATs wholes open

- Prevention of RTC denial-of-service, endpoint attacks: A B2BUA can
inspect each call attempt and in case of an attack detection prevent the
call from reaching its destination

- Wiretapping/CALEA: Since the B2BUA has access to the media streams,
those can be recorded

On the other hand, B2BUAs destroy the end-to-end call transparency and
they introduce a single-point-of-failure. That is why I believe that
SBCs lower the overall reliability of an RTC infrastructure. As an
example, a single SBC can be easily shut down by a DDOS attack, whereas
it is more difficult to attack many endpoints at once. And end-to-end
transparency is not only essential for reliability, but it is also
necessary for end-to-end call authentication/encryption (SIPS, H.235),
which IMHO is very important for e.g. prevention of SPiT or Caller-ID
falsification. Of course this can only be achieved by using client
certs, since shared secret solutions do not scale well enough.

Most of the functionality offered by SBCs can be achieved by other
means, like e.g.

- Near-end firewall traversal: Firewalls should not block RTC traffic!
Endpoint/host based security is a favorable approach.

- Far-end firewall/NAT traversal: STUN, TURN, ICE can be used for SIP
endpoints. H.460.18/19 for H.323 unfortunately depends on an SBC.

- Prevention of RTC denial-of-service, endpoint attacks: Deployment of
distributed RTC-aware IDS/IPS nodes offers better and more reliable
protection.

- Wiretapping/CALEA: hmmm, you probably need an SBC for that ;-)

The bottom line is that I'd use an SBC only for far-end FW/NAT
traversal, if at all. And if your firewall admin does not want to open
the ports for RTC traffic, you should try hard to convince him of the
advantages of a good IDS/IPS system.

Christian

--
Christian Schlatter
RTC Architect
ITS Telecommunications R&D
University of North Carolina at Chapel Hill

tel: +1-919-445-9253

sip:
h323:





--- End Message ---

-- 
Ben Teitelbaum   http://people.internet2.edu/~ben/