Subject: Re: [Sipping] What problems are SBCs addressing?

From: [email-masked]
Date: Fri, 15 Oct 2004 10:27:50 +0200

I think there are three things a SBC is adressing:

1. Converter from "lean" SIP to "full" SIP:

Most of the devices out there are not really SIP compliant (missing TCP
support, UDP fragmentation, sloppy routing support, REFER, DNS NAPTR/SRV,
MoH, etc etc). Most of the SBC address this problem by making these
devices a little bit smarter so that from the outside world they look like
"real" SIP user agents.

2. Things that a UA can't do

Here we are essentially talking about NAT. Especially in the Symmetrical
NAT case, even the smartest UA can not esablish two-way audio. A TURN
server would be an alternative, but the SBC approach (combined with other
features) seems to be easier. ICE can be nicely combiled with that.

3. Security and Billing

Hide information to the UA! For example, the UA should not see the routing
information (if the packet goes through a PSTN gateway or directly!). If
you want to record calls (caleia), the media must flow through a device
that can do the recording.

Christian

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> Sent: Friday, October 15, 2004 9:01 AM
> To: sipping
> Subject: [Sipping] What problems are SBCs addressing?
> 
> 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
> 
> 
> 

_______________________________________________
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: [email-masked]
Date: Fri, 15 Oct 2004 10:46:24 +0200

3. Security and Billing

Christian

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 18 Oct 2004 15:52:37 +0100

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>

> TLS is not end to end, it is hop by hop.  An SBC could implement
> sips and be able to inspect, but most don't.  That's not a standards
> problem; if they were 3261 compliant, they would implement TLS.
> Few do. S/MIME is end to end.  SBCs clearly break that.  There is
> tension between end users that want security and network operators
> that want to protect the network against theft of service, etc.
> It should be possible to find a standards-based way to do that,
> and I'm hopeful that the discussion Jonathan started will.

Ah, yes.  It's the end to end issues and the possible conflicts that I was
hoping to raise.

I assume by the term 'network operators' you mean carriers like AT+T, MCI
etc.  There may also be tensions between end users such as a cubicle
occupier who wants authenticated calls (or end-to-end encryption) in an
enterprise and the network administrator of the enterprise who doesn't want
to leave holes for malicious access (viruses, trojans, buffer overflows
etc).

> The discussion about packet marking/remarking was an example of
> something other than perimeter defense which is not currently
> addressed by standards.  If there was, SBCs would not need
> to rewrite SDP to force media to go through it.

Agreed, I lumped this under QoS.  (I'm assuming that by packet
marking/remarking this is with a view to prioritising traffic etc.)

> The categories may be helpful, but there are many ways to
> cut the pie.  Call Admission control is a QoS thing, for
> example.   Routing is a perimeter defense; all customer proxies
> route all calls to the network to the SBC.  It does the
> route beyond.  If the SBC wasn't there, the customer would
> have to do it.  Et cetera.

Agreed, there are many ways to cut the pie.  Re: the specific examples you
raise, I suppose I see the result of a call admission exercise as something
that may then kick off a QoS activity.  Having decided that QoS is needed it
then becomes an exercise in providing it.  I saw routing as a way of finding
where a person is at a particular time as 'routing as a service', whereas
routing to make data go through a control point as a means to an end that
was more to do with packet marking etc.

Maybe its best just to stay vague about the categories!

> Brian

Pete

> > From: Pete Cordell [mailto:[email-masked]]
> > Sent: Monday, October 18, 2004 4:53 AM
> > To: Brian Rosen; [email-masked]; [email-masked]
> > Subject: Re: [Sipping] What problems are SBCs addressing?
> >
> > The apparent incompatibility between proxy based perimeter defence and
> > things like TLS (e.g. end-to-end encryption/authentication) is something
I
> > want to emphasis.  (Most firewall functions are currently located at the
> > network perimeter.  There are motions to make all hosts in an enterprise
> > act
> > as their own firewall, but it may be a while before this is widely
trusted
> > and accepted.)  Even on HTTP, TLS isn't particularly firewall friendly
as
> > it
> > doesn't allow inspection (hence abuse of port 443).
> >
> > So my point is, perimeter defence and end-to-end
encryption/authentication
> > are both important security issues.  We need to avoid developing one
> > facility at the expense of the other.
> >
> > BTW - I've taken the liberty of re-ordering Brian's list into (rough)
> > categories:-
> >
> > Perimeter defence type things:
> > -----------------------
> > 2. Firewall
> > 3. DoS attack mitigation
> > 5. Service provider infrastructure hiding
> > 7. Legal Intercept (pjc - maybe a thing on its own e.g. regulatory.)
> >
> > QoS type things:
> > -----------------
> > 4. SLA enforcement/measurement/facilitation
> > 7. Packet marking and remarking
> > 9. Bandwidth management/policing
> >
> > Addressing IP deployment issues type things:
> > -----------------------------
> > 1. NAT traversal (and actual NAT functions)
> >
> > 'Regular' SIP proxy type things:
> > --------------------------------
> > 6. Routing services (pjc - I assume this is SIP routing)
> > 10. Call admission control
> > 11. CDR creation and other billing functions
> > 12. Protocol "repair"
> >
> > Misc!:
> > ---------
> > 8. Protocol interwork (pjc - really a GW function?)
> >
> > Of these categories, the first two are the ones I feel are not addressed
> > by
> > other SIP pieces.  With regard to NAT, there are other ways to do NAT
> > traversal.  However, if you are required to have a DMZ proxy then having
> > it
> > do NAT traversal as well may be conceptually easier than other
solutions.
> >
> > Pete.
> > --
> > =============================================
> > Pete Cordell
> > Tech-Know-Ware
> > http://www.tech-know-ware.com
> > For LMX XML to C++ binding see http://www.xml2cpp.com
> > =============================================
> >
> > ----- Original Message -----
> > From: "Brian Rosen" <[email-masked]>
> > To: "'Ram Dantu'" <[email-masked]>; <[email-masked]>;
> > <[email-masked]>
> > Sent: Saturday, October 16, 2004 6:54 PM
> > Subject: RE: [Sipping] What problems are SBCs addressing?
> >
> >
> > > The big one is that IETF specifications will REQUIRE TLS security for
> > > emergency calls (1-1-2/9-1-1/...) because location is carried in the
> > > signaling.  When I checked last, there were no SBCs which would
maintain
> > a
> > > sips connection.  That may have changed, but it's an issue.
> > >
> > > There are a number of other issues with respect to emergency calls
that
> > will
> > > require changes in SBCs, but with respect to security its maintaining
> > TLS.
> > >
> > > Brian
> > >
> > > > From: [email-masked] [mailto:[email-masked]] On
> > Behalf
> > > > Of Ram Dantu
> > > > Sent: Friday, October 15, 2004 6:00 PM
> > > > To: [email-masked]; [email-masked]
> > > > Subject: Re: [Sipping] What problems are SBCs addressing?
> > > >
> > > >
> > > > We are having a workshop on this topic (VoIP Security).
> > > > In particular, we would like to work on the issues what
> > > > SBCs are not addressing. Let me know if you need
> > > > further information
> > > >
> > > > http://www.globecom2004.org/images/W05_CFP.pdf
> > > >
> > > > Ram Dantu
> > > >
> > > >