[VOIPSEC] Session Border Controller use

[Dorgham Sisalem]

Hello

On Wednesday, June 21, 2006 at 3:46 PM your wrote:

mg> Bruce,

mg> 1. You don't need an SBC for handing calls to the PSTN.
right, the PSTN gateway are hidden behind the proxy and should be
configured in such a manner as to only accept signaling traffic coming from the
proxy
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. An SBC would only increase
the complexity and add unnecessary delay and processing. Not even
3GPP IMS suggest using SBC for network boundaries
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.

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)
mg> session detail records,
Session records are best collected at PSTN gateways (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
mg> QOS mediation
I am not sure how a component in the middle of the network will be
capable of improving any QoS? If the parts of the network before it or
behind lose packets then the SBC will not be able to do anything about
this. The only thing an SBC could do is to smooth out jitter, but this
can only be achieved by adding more delay (i.e.,  possibly
reducing the QoS)

Cheers
mg> , and not really for security, although they may do some rate
mg> limiting for certain messages. Some SBCs will look at media, just to monitor
mg> whether media comes to ports after a call has been terminated. 

mg> Best,
mg> Micaela
mg> --------------------------------------------------------------
mg> Micaela Giuhat
mg> VP PLM
mg> Sipera Systems
mg> (w) 214 206 3294
mg> (c) 214 418 8547
mg> www.sipera.com
mg> ---------------------------------------------------------------

mg> -----Original Message-----
mg> From: Voipsec-bounces at voipsa.org
mg> [mailto:Voipsec-bounces at voipsa.org] On
mg> Behalf Of Kaalund, Bruce
mg> Sent: Wednesday, June 21, 2006 8:21 AM
mg> To: Voipsec at voipsa.org
mg> Subject: [VOIPSEC] Session Border Controller use

mg> I have questions about the use and placement of Session Border
mg> Controllers.  I have a rather general understanding of their purpose and
mg> use, but I am being questioned about placement in the network.  My
mg> questions are as follows:
 
mg> 1.  When the end user and the Layer 2 Switch (CMS, Media gateway, etc.)
mg> reside on the same network, and the calls are passed to the PSTN, is
mg> there a need for the SBC?  If so, where should the SBC be placed?
 
mg> 2.  When the end user resides on one network, and the Layer 2 Switch
mg> resides in a hosting facility on a different network, is there a need
mg> for the SBC?  If so, where should the SBC be placed?
 
mg> 3.  I see a lot of value in the SBC for the protection of signaling
mg> traffic.  However, I have not been convinced of the value of using the
mg> SBC for bearer traffic.  I believe an attack on a particular call is
mg> dependent upon either obtaining and replicating, or corrupting the
mg> signaling traffic, in order to affect the bearer traffic of a particular
mg> call.  Why would I want to run the bearer traffic through the SBC?
 
mg> Any and all opinions would be greatly appreciated.  Thanx.
 
mg> Bruce A. Kaalund
mg> Director, Product Security Architecture
mg> National Engineering & Technical Operations
mg> Comcast Cable
mg> 1500 Market Street
mg> Philadelphia, PA 19102
mg> Telephone -- 215-851-3303
mg> e-mail -- bruce_kaalund at cable.comcast.com
mg> Doveryai No Proveryai - Trust but Verify
 
mg> _______________________________________________
mg> Voipsec mailing list
mg> Voipsec at voipsa.org
mg> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org



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