[VOIPSEC] Session Border Controller use

[Hadriel Kaplan]

Hi Dorgham, comments inline...

> -----Original Message-----
> From: Dorgham Sisalem [mailto:sisalem at iptel.org]
> Sent: Friday, June 23, 2006 6:23 AM
>
> with IPSEC and TLS we can ensure that we are only getting traffic from
> peers that we know. The policy of what to do with such traffic is then
> the job of the proxy. Please let me know what much else is left.

There's a lot, but I'm not sure how much is specific to certain SBC vendors
vs. others, and I have no interest in providing competitive information to
the others, nor touting my company's product over others.  I've been trying
to keep this at a product category level instead of specific product
capabilities.  

>From a higher level, some of the basic issues are of control and trust.
Just because you know signaling is going to/coming from a specific peer and
no one else can view it across the link between the two, means nothing about
what happens inside the peer, or at their peers or customers.  The issue is
that the local service provider cannot fully trust the peer to secure their
infrastructure, for signaling or media.  Obviously one can perform plenty of
"policies" as a stateful proxy - indeed many SBCs can be in proxy mode, but
they're usually run in b2bua mode in order to do things like total topology
hiding and service/application-specific control.  Couple that with the
interworking/interop things they have to do for both signaling and media,
and the reasons for running in b2bua mode increase.


> To be honest I am not sure what this answer really means. If you
> checked the 3GPP specifications in detail you will find that all the
> x-CSCFs are working in proxy mode (S-CSCF can maintain session state
> though). Sure the SBCs do much more than this, But this is exactly
> what we are debating here: is this "much more" is really needed.

Both P-CSCF and IBCF switch to b2bua mode for some cases, and more
importantly can control relay of media (ie, the BGF).  They are not true
proxies as the IETF defines the term, and that's what I think of when
someone says "proxy".  I think you must feel SBC = b2bua?  It is difficult
to pin down a solid definition of SBC.  Some people feel it's only an SBC if
it relays media, some feel it's only an SBC if it's a b2bua (although there
are tons of b2bua's that are not SBCs).  It's somewhat of a Venn diagram,
because many SBCs can be configured to be in proxy mode or not, and/or not
relay media.  It's kind of like defining a firewall or a router.  Firewalls
can be in many modes, doing different things.  Some of those things are very
simple access policies, which home NATs also do, but they're not considered
firewalls.  Routers typically forward based on L3 info, and segment L2
domains, yet an L3-switch is capable of doing some of the same things and
also switch at L2, and routers can also just be enabled as an LSR and
forward based on mpls labels.



> HK> Yeah right.  Exactly how many deployments of STUN/TURN/ICE/Outbound
> are
> HK> there?  Have you read the drafts?  And you think the way SBCs solve it
> is
> HK> more complex than that???
> You will be surprised. Out of the 10 large VoIP deployments in
> Germany, the 10 use STUN. For those cases where STUN can not be used,
> a media proxy is deployed -which is still a much simpler component
> than an SBC

That's interesting, since I personally know of a few large voip deployments
in Germany who happen to use SBCs. :)  I don't know if they're the 10
largest for voip, but they're in the group of 10 largest network and telecom
providers.  

An SBC relaying media is a media proxy.  Whether it is more complex or not
depends on your point of view I guess.  Nothing seems simpler to me than
being able to use any UA behind any NAT type, and not doing a bunch of
offer/answers to get a call working, but maybe that's just me.


> * The SBCs are distributed in the network so as to avoid the above
> scenario. As the SBCs will need to authenticate the users, they will
> need to get access to the database of the provider -which is usually
> in a central location. Distributing this information to all the SBCs
> will be a nightmare.

Yes, this is the most typical scenario, and no the SBC does not need to
access a central database out-of-band, although that's one way to go (ie, a
RADIUS model).  But the authentication info and its distribution is already
available through SIP.  


> sounds like we are reinventing PSTN here. I am sure there is a good
> business case behind this scenario but considering the abundance of
> bandwidth in the core networks I am not sure if we are solving a real
> problem here.

I find that the phrase "re-inventing the PSTN" gets used whenever someone
doesn't like something someone else does.  :)  Are we trying to provide
service that's just as good or better than the PSTN?  Yes.  Are we trying to
support new applications/services that the PSTN couldn't?  Of course.  But I
think the part you may find offensive is we give total control to the
operator, and let them decide how much to control or not, as opposed to the
end user equipment.

Whether there is an "abundance" of core bandwidth does not matter.  For one
thing, I'm not convinced how abundant it really is at the micro level; the
highway from my house to my work is only 30% utilized, yet every day twice a
day there's a traffic jam.  But whether the real traffic model of core links
actually impacts voip, especially as more UDP without congestion control
gets used for voice and video, is something we'll find out I guess.  It
doesn't matter though.  The property of SBC media relay I talked about
allows you to do it on the access and peering links as well.  Some network
points already control this through other means (e.g., PacketCable DQos
control), and others don't.  It's not a major deal - just answering your
question of how it could help.

-hadriel