Subject: [Sipping] What problems are SBCs addressing?

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 15 Oct 2004 00:35:22 -0400

Folks,

As many of you know, there are a large number of products on the market 
these days under the general moniker "Session Border Controller"; 
generally these are B2BUas that play some kind of policy enforcement and 
control function, typically at trust boundaries.

Our specifications don't define how B2BUas should operate, and they say 
nothing at all about an SBC (although they do address many problems that 
relate to inter-domain operations and trust boundaries). However, the 
preponderence of these devices in the market and in VoIP networks seems 
to indicate that there are real problems that providers believe they 
have, which they feel these products are solving for them.

This begs the important question - what are those problems, and are 
those problems for which the IETF has produced specifications to 
address? If not, is there a need to do so? If yes, are these products 
using those specifications, and if not, why have those solutions not 
seen implementation and/or deployment?

Put in another way, sipping is all about requirements and problems, and 
it is clear that there are one or more problems here somewhere. Do we 
understand those requirements, and do we need to produce specifications 
to address them?

This is a fairly meaty topic, one for which I expect to see lots of 
emails in reply to this note suggesting answers ;) Furthermore, we are 
planning an informal get together at IETF 61 to continue the dialog, 
focusing squarely on understanding requirements and specification gaps. 
Details TBA shortly. Whether one likes the solutions that are out there 
or not, the first step in doing anything is to understand the 
requirements. I really want to do that.

I think it's important to have this discussion now, while there is still 
time to address these issues with standards-based solutions. To 
paraphrase Spencer Dawkins' recent note - I don't want to have a BoF 
session three years hence called "son-of-behave", where we discuss what 
an SBC should do, wishing that we had written specifications three years 
earlier and thus avoided the interop mess that had resulted. Given the 
recent concerns about GRUU and SIP identity operation through SBC, this 
is even more telling.

Inputs from people who work for vendors of such devices, your input is 
most welcome..

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 15 Oct 2004 19:06:22 +0100

I'm not actually working for any vendors at the moment, so feel free to
dismiss my input!!!

If you've got this far, I think that SBC's in the broadest sense offer:

1)
Perimeter defence - not sure if that's the right term, but much like a mail
server in the DMZ provides protection at the SMTP level, an SBC in (or
around) the DMZ can provide protection at the SIP/RTP level.  My feeling
that it is unreasonable to expect a standard firewall (what ever that is) to
be best of class in all protocols, so proxies can help.  The firewall makes
sure packets go to/from the relevant proxy, and the firewall trusts that the
proxy will do its job (because the administrator told it to!).

This 'bump' in the path is a problem for end-to-end security, but my feeling
that most organisations forced to choose between perimeter defence vs.
encryption and authentication would (at the moment - spam is an issue!) go
for perimeter defence.

A number of SBCs are outside the DMZ.  This makes it harder for the firewall
to trust, but this is motivated by outsourcing, much as SMTP proxies are
outsourced.  Basically its a question of how much expertise is around to
manage the devices.  The latter seems to be a practicality of the real
world.  (This is really something I observe rather than strongly defend.
Mind you, the customer's always right!)

2)
There's a hope that SBC's can play some part in the QoS management puzzle
primarily in the relatively bandwidth limited access link.  I think it's
only a piece in the puzzle, and there may be other ways to do it.

That's my two cents!!!

Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware
http://www.tech-know-ware.com
For LMX XML to C++ binding see http://www.xml2cpp.com
=============================================

---

From: Ben Campbell <[email-masked]>
Date: Thu, 28 Oct 2004 16:56:40 -0500

Apologies if this one has already been mentioned, but if I am reading 
it correctly,  the "session" privacy mode in rfc3323 seems to imply 
something that looks a lot like an SBC.

On Oct 14, 2004, at 11:35 PM, Jonathan Rosenberg wrote:

> Folks,
>
> As many of you know, there are a large number of products on the 
> market these days under the general moniker "Session Border 
> Controller"; generally these are B2BUas that play some kind of policy 
> enforcement and control function, typically at trust boundaries.
>
> Our specifications don't define how B2BUas should operate, and they 
> say nothing at all about an SBC (although they do address many 
> problems that relate to inter-domain operations and trust boundaries). 
> However, the preponderence of these devices in the market and in VoIP 
> networks seems to indicate that there are real problems that providers 
> believe they have, which they feel these products are solving for 
> them.
>
> Put in another way, sipping is all about requirements and problems, 
> and it is clear that there are one or more problems here somewhere. Do 
> we understand those requirements, and do we need to produce 
> specifications to address them?
>
> focusing squarely on understanding requirements and specification 
> gaps. Details TBA shortly. Whether one likes the solutions that are 
> out there or not, the first step in doing anything is to understand 
> the requirements. I really want to do that.
>
> I think it's important to have this discussion now, while there is 
> still time to address these issues with standards-based solutions. To 
> session three years hence called "son-of-behave", where we discuss 
> what an SBC should do, wishing that we had written specifications 
> three years earlier and thus avoided the interop mess that had 
> resulted. Given the recent concerns about GRUU and SIP identity 
> operation through SBC, this is even more telling.
>