[VOIPSEC] RE: Query on typical SBC implementation

[Geoff Devine]

Bob Wise writes:
> Are SBCs typically positioned behind a firewall or in front of it?
> I've done some googling on this subject and haven't found any
> references to best practices for network deployments of SBCs.
>
> I can think of arguments either way.
> 
> In any case, doesn't it seem that the firewall and SBC appliances
> will merge?

You'll see the picture drawn both ways.  The SBC can either be a core
network element or a CPE device.  When it's a CPE device, it's usually
drawn beside the firewall, not behind it.  It really depends on who owns
it and exactly what trust relationship is being policed.  

For example, two VoIP operators are likely to each put their own SBC at
the place where the two networks meet to police service level agreements
and provide data for reconciling billing.  

In the case where an operator is trying to protect their core VoIP
services from the anarchy of the internet, they place it between their
subscribers and their walled garden.  In that case, the SBC serves a
number of functions including hacking SIP signaling to cope with NAT
traversal through home routers, enforcing policy on SIP signaling so it
doesn't damage their core VoIP network elements, lawful intercept/CALEA,
codec transcoding (nobody has built this yet but it's on all PowerPoint
slides), and anonymizing the CPE IP address for media and signaling
flows to preserve privacy.

When the SBC is CPE gear, you typically are using it in some kind of
VoIP PBX arrangement.  You're asking it to perform functions that a
firewall doesn't normally do like give you detailed quality metrics on
media streams.

Architecturally, I tend to think of an SBC as being a specialized sort
of firewall.  It's typically intended to deal only with known media and
signaling flows and you don't point all your internet traffic at one.
VoIP is a bandwidth-hungry application.  An SBC with an ingress and
egress GiG-E can only drive about 4,000 uncompressed voice calls (20,000
to 50,000 subscribers depending on your Erlang model).  If you're
running security on your signaling stream, the SBC has to terminate it
since it is modifying and policing the SIP signaling.  If you're running
media security and you're providing functions like CALEA and codec
transcoding, you also need to terminate the media stream security.  From
a SIP architecture point of view, an SBC is sort of a SIP Back to Back
user agent.  SIP purists who believe in endpoint to endpoint signaling
loathe inserting these sorts of devices into the network but it's what
it takes if you need to harden things.

If you look at what the cell phone people are doing in this space, they
make the SIP edge proxy (P-CSCF) be a back-to-back user agent and do the
SIP policing.  They use tunnel-mode IPSec VPN to enter their walled
garden from subscriber VoIP devices that aren't cell phones with SIM
chips in them.  The tunnel also enables NAT traversal.  The down side is
tunnels create header overhead though you can compress most of it away.

As a service provider, you're forced to pick one solution or the other
if you really want to harden your service.  Neither is perfect.

Geoff