[VOIPSEC] Session Border Controller use

[Dorgham Sisalem]

Hello Hadriel

thanks for your replies, please see comments inline

Best regards
Dorgham


>> mg> 2. You will need an SBC between the two networks. The best placement
>> will be
>> mg> before the layer 2 switch on the hosting center (as close to the edge
>> as
>> mg> possible).
>> 
>> I am not sure what the added value of SBC might be here. If we want to
>> secure the communication between two peer networks then there are
>> already standardized tools based on TLS or IPSEC. 

HK> TLS and Ipsec are encryption and/or authentication mechanisms between 2
HK> points.  That's it.  If that's what you think is synonymous with security,
HK> and all you think is required to secure a peering border (or access, or
HK> anything), then sure you could do them on a proxy or the softswitch or
HK> whatever.  

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.

>> An SBC would only
>> increase
>> the complexity and add unnecessary delay and processing. Not even
>> 3GPP IMS suggest using SBC for network boundaries

HK> Actually, they do.  They specify functions, not equipment.  The
HK> IBCF/IWF+I-BGF functions are an SBC on the peering side, and P-CSCF+C-BGF
HK> are an SBC on the access side.  They can be decomposed or integrated, that's
HK> up to the operator to decide.  Of course most SBCs do more than those
HK> functions, for a lot of reasons.

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.

>> mg> 3. SBCs are mainly use to solve demark issues such as FW and NAT
>> traversal,
>> IETF has already provided a set of solutions allowing NAT traversal of
>> all kinds. Using an SBC would mean using the most complex
>> approach for NAT traversal always. This will not only increase the
>> complexity
>> and costs of the network but also might increase the delay and
>> interoperability problems.

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

>> mg> as well as provide session admission control,
>> SIP already provides sufficient admission control (I do not think
>> that a proxy can do more here than the proxy behind it could do)

HK> SIP is a protocol, not a piece of equipment.
HK> SBCs are typically not
HK> proxies, and usually can do more than a proxy behind them for admission
HK> control, but obviously that depends on the proxy's capabilities.  You
HK> definitely don't have to be an SBC to do admission control, it's just
HK> something they also do and have been doing for a long time.
so we agree that SBCs are not needed here.

>> mg> session detail records,
>> Session records are best collected at PSTN gateways 

HK> Most service providers collect them at multiple places.  Not all calls go
HK> to/from their PSTN gateways (and hopefully even less in the future).  Most
HK> service providers I've seen seem to use the ones generated by their
HK> softswitch/S-CSCF for actual billing purposes, but collect them from many
HK> elements for tracking, auditing, and troubleshooting purposes.
so again, we agree that SBCs are not really needed here

>> (for the SBC to
>> provide CDRs with the same level of accuracy it would have to also
>> route media traffic. This would in general mean longer media paths
>> -i.e., higher delay-, even higher hardware costs and a more complex
>> network architecture

HK> Only for non-infrastructure providers. (i.e., ones without a physical
HK> network) 
even if the provider has a physical infrastructure using SBCs would
make life much more difficult. There are basically three scenarios
* the provider has all of its SIP equipment in one place and puts the
SBC in from of it. This means that all the VoIP traffic will have to
go to that place. This does mean that the VoIP center will need to
have a few giga access lines
* 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.
* In the third scenario the SBC would be close to the Database but the
media routing capabilities of the SBC would be distributed. While this
solves the problems above it will still require close synchronization
and secure links between distant nodes
HK> Then you're not thinking of it in terms of routing.  Routing doesn't follow
HK> the shortest physical path, the least jitter path, nor the highest bandwidth
HK> path (although it typically does do this last bit in an IGP because
HK> costs/metrics are typically set to reflect link speed, but it's not
HK> necessarily available bandwidth).  An interesting property of an SBC in
HK> terms of media relaying is that you always know the source and/or dest
HK> addresses of the media, and it can steer the media and mark it, put it in a
HK> different VLAN, etc.  So if you own the network infrastructure, you can use
HK> that to your advantage and provide either diffserv, policy routing, or
HK> MPLS-TE engineered paths that are only available/used for media and not
HK> best-effort data.  In effect you can make the media go a non-best-effort
HK> path which is better, if you wish to, and yet control what traffic and what
HK> amount of it gets into those engineered paths.  Note that most SBCs in the
HK> service provider market do media-relaying in hardware with the same
HK> jitter/latency as one router hop.  
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.

cheers
HK> -hadriel



HK> _______________________________________________
HK> Voipsec mailing list
HK> Voipsec at voipsa.org
HK> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org