[VOIPSEC] Session Border Controller use

[Dorgham Sisalem]

Hello

OG> If the service provider want users to have no direct access to the
OG> gateways you must use a SBC. The interest is that the user  won't be
OG> able to hack one of these gateways of various marks for instance. Maybe
OG> you would say it will be possible to hack the SBC. Sure, all is possible
OG> but the number of security holes will be obviously limited.

I am not really sure I understand this reasoning. Why would be hacking
an SBC less dangerous than hacking the gateway. If I manage to bring
the gateway down then all communication with PSTN through this gateway
will be impossible. But the provider usually has a lot of other gateways to chose
from, so this does not sound terribly dangerous. If I manage to bring
the SBC down, then the whole SIP service behind it (proxies and
gateways) will be useless and I would assume that there will be less
SBCs deployed than gateways.
>>
>> 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. An SBC would only
>> increase
>> the complexity and add unnecessary delay and processing. Not even
>> 3GPP IMS suggest using SBC for network boundaries
>>  
>>
OG> Using the tools mentionned won't be easy especially if we must manage
OG> several peer elements. The issue here is not only security but access.
so how would the SBC solve this?


OG> Right on the fact that IETF(STUN,TURN,ICE,...) and ITU (H.460.17,18,19)
OG> provide a lot of solutions not only for NAT traversal but for optimized
OG> RTP paths. WRONG on the fact that Hosted NAT Traversal thanks to a SBC
OG> is the most complicated solution. This solution works for all types of
OG> terminals and softswitch. This solution works also for all kinds of NAT
OG> boxes... With all the other solutions you need special compatibility
OG> with the solution like a STUN client in the terminal and a STUN server
OG> for instance. If you want to be compatible with all types of NAT (full
OG> cone, restricted cone, port restricted cone or symetric) you MUST use
OG> any kinds of media packets Relay in your architecture. Delays shouldn't
OG> be perceptible. INTEROPERABILITY PROBLEMS are usually SOLVED using a SBC
OG> (With our products it is possible ;-)). As SBC is tested with a lot of
OG> terminals from one side and a lot of VoIP servers on the other side.

I agree that with SBC all the NAT issues are solved but this does not
contradict the statement that it is still the most complex one. With a
combination of STUN and media proxies, all VoIP providers in Germany
-and many other countries- have solved all of their NAT problems. Sure
this requires STUN, but I hardly know of decent VoIP user agents that
do not support STUN. The combination of STUN and media proxies does
not require components that maintain session states or complex routing
strategies. SBC solves the same problem by maintaining session state,
which means that it
* requires a more complex reliability architecture
-as you need to duplicate session state in a same manner as current
SS7 switches do-
* you will need to maintain more memory and CPU to accommodate the
processing

>>
OG> For QoS, a SBC can offer the insurance not to exceed the negotiated flow
OG> (audio/video codec rates) for a call according to SDP or H245 
OG> informations for example. It may also be able to change these 
OG> informations in order to limit the flow, forbidding the use of a codec.
OG> It can also permit to detect problems thanks to RTP statistics and
OG> alarms. Packets lost can't be avoided.
What is the practical gain of all of this? I was under the impression
that ISPs are in the business of selling traffic and not limiting it.
From a user perspective if my VoIP provider
prohibits me from using video telephony in addition to voice then I
will make sure to get another VoIP provider.

cheers
OG> Regards,

OG> Olivier GRALL.
OG> Project Manager
OG> NETCENTREX
OG> Converged IP Communications