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

From: "Francois Audet" <[email-masked]>
Date: Fri, 15 Oct 2004 15:21:35 -0400

I assume that you are only planning to focus on the SIP aspects.

One thing they do is bridging between two different domain, in particular
for security.

While this is not terribly difficult for SIP/TLS, it is considerably more
awkward/nasty for sRTP.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jonathan Rosenberg
> Sent: Thursday, October 14, 2004 21:35
> 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: "Brian Rosen" <[email-masked]>
Date: Fri, 15 Oct 2004 16:15:38 -0400

First of all, thanks Jonathan for starting discussion on this very important
issue.

Most of the SBC pitches I have seen focus on:
1. NAT traversal (and actual NAT functions)
2. Firewall 
3. DoS attack mitigation
4. SLA enforcement/measurement/facilitation
5. Service provider infrastructure hiding
6. Routing services
7. Legal Intercept
8. Protocol interwork
7. Packet marking and remarking
9. Bandwidth management/policing
10. Call admission control
11. CDR creation and other billing functions
12. Protocol "repair"

That's a pretty good list.  There is overlap, and every vendor has some
twist on flavors of these things.

Brian
________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Francois Audet
Sent: Friday, October 15, 2004 3:22 PM
To: 'Jonathan Rosenberg'; 'sipping'
Subject: RE: [Sipping] What problems are SBCs addressing?

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Sat, 16 Oct 2004 00:06:27 -0400

This looks like a good list to start with (I'd say this captures a good
50-60% of the use cases at this point). However, I think a better point to
start with on this list would be the B2BUA, which applies to about 30-40% of
the functionality of the SBC (the rest being related to other protocols and
supporting functions). B2BUAs are used at network core as well as
application servers.

I see this discussion similar to previous threads on B2BUAs and
interworking. From a standardization perspective, we can standardize the two
sides of an intermediate entity. The rest is determined by a higher layer
(session/application/policy etc). 

-Medhavi.

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of Brian
> Rosen
> Sent: Friday, October 15, 2004 4:16 PM
> To: 'Francois Audet'; 'Jonathan Rosenberg'; 'sipping'

---

From: Harry Behrens <[email-masked]>
Date: Sat, 16 Oct 2004 10:08:11 +0200

First of all I fully agree with what Medhavi says. One will find that a 
lot of
the functionality of an "SBC" is based on operating a B2BUA.

On a more general note:

I caution from "overloading". Looking at Brian's list, I ask myself:
what is left of the network when you take away all of the functionality
supposedly handled by the "SBC"?
The group will never get anywhere practically valuable if you aim at
"solving the question".
A best practice or description of state-of-the-art seems more modest and 
sensible.

This is after all a moving target.

Just my 2c,

    Harry Behrens

Medhavi Bhatia wrote:

>>First of all, thanks Jonathan for starting discussion on this very
>>    
>>
>important
>  
>
>>issue.
>>

---

From: "Brian Rosen" <[email-masked]>
Date: Sat, 16 Oct 2004 13:54:30 -0400

The question Jonathan raised was "what problem are SBCs solving?"
While I didn't phrase my response in terms of problems, just stating what
the effect B2BUAs have on a call is pretty far from what was asked.

I don't agree with Medhavi at all.  A B2BUA can be operated in such a way
that it is completely transparent to the signaling, and does not provide any
of the functions I listed.

I'm assuming Jonathan wants to start efforts that lead to STANDARDIZED ways
to solve the problems that SBCs are solving because the way SBCs work is to
break the end to end model of SIP (and the Internet).  I think he believes,
as I do, that it's a BAD THING to break e2e.  An example is that an SBC that
rewrites SDP (to force media to go through the SBC) breaks any S/MIME
security on the body.

We're breaking down the problem.  One of the functions SBCs do that I listed
was to mark (or remark) packets.  If a network offers some form of QoS like
DiffServ, they may mark voice packets belonging to calls admitted to the
network to get "special" treatment by the network.  Some form of priority,
for example.  Network operators want to make sure that only calls they
specifically admit to the network can have media packets marked for special
treatment.  They want to make sure that someone doesn't steal services by
marking packets inappropriately.

So the SBC does call admission control (which may limit the number of calls
admitted so that the total amount of "special treatment" packets in the
network doesn't exceed the capacity of the network to provide the special
treatment.  That part is also "SLA enforcement/facilitation".  It rewrites
the SDP addresses so that media flows through the SBC rather than direct to
the other end.  It then tracks all of the media packets flowing through it
(firewall functions), and makes sure that those for calls which it has
admitted have the correct packet marking.  It either unmarks packets it
doesn't recognize, or may even drop them.

To standardize the problem the SBC is solving is fairly difficult.  We might
provide a way to explicitly route packets through (normally passive) packet
relays that monitor marking that is explicitly signaled.  That would provide
a monitoring point that was explicit rather than require the SBC to rewrite
the SDP.  

Brian

> From: Harry Behrens [mailto:[email-masked]]
> Sent: Saturday, October 16, 2004 4:08 AM
> To: 'sipping'
> Cc: [email-masked]; 'Brian Rosen'; 'Francois Audet'; 'Jonathan
> Rosenberg'
> Subject: Re: [Sipping] What problems are SBCs addressing?
>

---

From: "Medhavi Bhatia" <[email-masked]>
Date: Sun, 17 Oct 2004 00:06:03 -0400

> of the functions I listed.
[MB] I don't think I hinted at all B2BUAs having to do some kind of SBC
functions (I think I did mention application servers/proxies as other
applications of B2BUA, so varying degrees of transparency are possible).
However I do think there are some misconceptions about SBCs breaking those
transparencies and that an SBC is always a B2BUA underneath rewriting SDP.
These problems are probably solvable without using B2BUAs. However, a
different solution/approach to these problems does not change the role or
specification of the SBC in each of the application/use cases. For example,
when a service provider wants an SBC which solves the lawful interception
problem or implements QoS in the network, they don't care whether it is a
B2BUA or a proxy,  or if SDP is being rewritten and how (the way that these
problems are solved currently is using B2BUAs). In scenarios where e2e
security is important, clearly there must be cooperation between the end
user and the intermediate network as the goals are conflicting. However the
nature of the solution does not change what these elements are called today
by customers/service providers.

> rewrites SDP (to force media to go through the SBC) breaks any S/MIME
[MB] Again I think what you are trying to say is that the way SBCs are
implemented today (which is using B2BUAs), e2e security is not supported.
However, there is no reason why it shouldn't and I believe that it will once
the network and the user cooperate, and there are several approaches like
the policy framework/nsis for some of this stuff. Whatever the solution is,
it will be implemented and the net "thing" will still be called an SBC. Each
kind of SBC (and some of which you mention below) is really a set of
requirements.

> marking packets inappropriately.
[MB] I think I can add some more requirements to the QoS set. It is both the
policing and facilitation as you mention below. However, I think there are
ways to do this w/o rewriting SDP. QoS measurement is another requirement to
consider. Breaking down each of these problems sounds good, but there are
too many of these (real) problems. Don't we already know the common set ? I
believe it is: any entity in the path of a session may like to know who the
originator is (for SLA purposes, this may be the end user or previous hop),
what resources are being really expected, the provision/detection of the use
of these resources and their policing. All this and e2e transparency.

> a monitoring point that was explicit rather than require the SBC to
rewrite
[MB] I haven't looked at the nsis work recently. From what I understand that
is the kind of cooperative mechanism SBCs will develop.

-Medhavi.

> > >start with on this list would be the B2BUA, which applies to about
30-40%
> > of
> > >interworking. From a standardization perspective, we can standardize
the
> > two