SBC ad-hoc notes

SIPPING Ad-Hoc on Session Border Controllers
November 9, 2004 1900-2100

Jonathan Rosenberg and Gonzalo Camarillo at the table in the front of the room (do you actually CHAIR an "informal get-together"?)

"There are more people in this room than there are SBCs in the world..."

Note-takers - Spencer Dawkins and ...

Introduction

SBCs being widely deployed and widely used
IETF says little or nothing about SBCs now, and interoperability concerns are growing
Can we get our heads out of the sand before it's too late, and make an informed response (which may be sitting quietly, but it's informed)
We start with higher-level requirements in the SIP community - then we can talk about what we already have, and what we can develop (not at this meeting, though).
Please avoid solutions, dogma, and religion.
Sridhar - two hours is way short for us on this topic! We need context-setting - that's what we plan to do tonight.
Keith - what's an SBC? Anything that's not a UA and not a proxy? Not constrained at this time.

Discussion

Good decision to hold this session - where are SBCs in the network? Start from an interconnect point of view?
Is border a common feature? Jon has seen several - NNI between service providers, Perimeter defence, ...
Jim at Acme Packet - acess control (white list/black list on IP address basis) limiting who interacts with a service provider. Hiding topology using NAT techniques/route stripping so IP addresses of VoIP resources aren't visible (avoid DoS). Business requirement?
Kent Fisher - I have 3-4K media gateways and don't want to change 10 percent of router ACLs every month - this is network management issue, not a trust issue. Signaling can be limited, but need to know where the media is coming from.

Peers want static IP addresses because THEY don't have SBCs...
From a service provider experience, it's hard to know what partner's infrastructure is - we're creating a trust boundary.
Want to monitor peers - how many calls, how much bandwidth? Doing SLA management - am I meeting my SLA? Don't want domain names all over Vias, etc. Some customers think they want to change all the headers and remove all the domain names! People are looking deep into packets
A lot of IETF working groups are relying on source address spoofing, other working groups are giving up on source addresses because of spoofing. What other solutions are there? Maybe none, right now. What could we create? If someone had a SIP-aware firewall, that would be better, but no one has them now in major deployments.
Different levels of security? What are they? Carriers have to decide what policies are - SLA, no idea who some endpoints are, and everything between these extremes. What do we do with endpoints that are very untrusted?
Jiri - I don't understand these scenarios - need more definition to understand these desires and the requirements they are leading to. We're managing the Internet between networks.
Spencer - end-to-end security? We're pretty much middle-to-middle here.
Ben - we have some policies they want to invoke, and they have an authentication problem. That's what we spend all our time talking about in working groups today. Sometimes authentication of original sender is good enough, other times not.
Jonathan - we have fairly robust procedures for SIP, but nothing for RTP about next-hop authentication, etc. How to turn off RTP transmissions for inactive sessions?
Some vendors are implementing signaling and media in same box - we're on the edge of solution space, though - IP addressing issues are classic, traffic engineering is a problem, some regulatory issues are problems, basis for billing/accounting, basis for SLAs, echo cancellation...
Policies usually based on either From or Via. Our problems are policy and topology hiding. What about Lawful Intercept?
"Deep packet inspection?" - is this session-based? Why, if we need packet inspection? Why not all traffic? RTP stream may only be valid for a session. If the media should have stopped, it needs to stop. We are doing this now, because when we didn't do it, we had problems with unauthenticated streams.
Henry - there's an economic reason for SBCs, too. Have to engineer every access for every customer. It's easier to put an SBC on our premises, and it's cheaper, too.
Cullen - So, we're doing NAT traversal, too? Maybe this is a temporary solution, but SBC vendoes say this is the principal reason for SBCs. Also have old/new equipment problems
Spencer - we're talking media streams, not just signaling streams? Yes.
We're talking about excuses, not problems. The problem is that the carrier wants to control everything. That's the problem SBCs are solving. When we solve the stated "problems", people will come up with new justifying problems.
Francois - we're talking about carriers, but enterprises - especially large enterprises - have very similar requirements - let stuff into the network without blowing their security away, provide a "funnel" for this traffic, identify non-compliant implementations. We have SBCs at enterprises talking to SBCs at carriers.
Dean - "other traffic" - in a lot of cases, the presence of "other traffic" is an operational error, because carriers are doing application-level routing disjoint from IP routing topology.
Piolycom - requirement we see from SBCs is about NAT traversal. Then we start adding additional functionality on the box we just added, start making routing decisions, etc. Because SBCs change payload, they look like a man-in-the-middle attack for end-to-end integrity checking.
Jim - sometimes the SBC aids NAT traversal, sometimes the SBC acts like a NAT. Cable deployments with all-private networks have to go through something LIKE a NAT, and carriers like this want to base decisions on signaling state, etc. Trying to avoid MPLS, traffic engineering, etc.
SBCs becoming a single layer-three device to accept calls from (not just everyone on the Internet). Carriers don't want to give their customers visibility to other entities, because the customers can cut the carriers out of the value chain.
SBCs allow people at enterprises to bypass firewall restrictions (for specific applications).
Are SBCs going to change media addresses?
If you look at the perimeter of a network, people want to deploy firewalls, etc. anyway. SBCs help add capacity for firewalls. SBCs prevent overloading of other network elements.
Alan - usually layer-seven requirements that need to be enforced at a few enforcement points, with no generally-advertised routes.
Need to think about SBC's ability to "trumbone" media for users behind the same firewall.
Ben - sometimes this is political - service management departments that won't talk to firewall departments. We're talking about a political perimeter.
Ed - want to troubleshoot calls - how to trace one-way calls without an SBC or something like it? SBCs have the concept of a session - everything else measures packets. How to pick off DTMF digits in an RTP stream? SBCs have this capability, what else does? Want to control how many sessions are coming from enterprises, from peer networks, and make policy decisions based on these numbers. SBC is the only thing that can do that function today. SBCs are providing conferencing capabilities, IVR capabilities, etc. at the application level.
We're talking about service normalization extrapolated to the media - transcoding, for example, or bridging from old equipment to new equipment.
If the destination is interpreting the digit, why is the SBC intercepting it? We don't understand? Think calling card applications that do 3PCC (especially pre-KPML applications).
What does peering look like with SBCs? "Controlling trunks." Will SBCs control routers? No, this was confusion.
We want to identify voice, support SLAs, and receive payment for this. This is a QoS guarantee issue for voice, rather than using RSVP or Diffserv, and it's between two providers, not between two hosts.
Paul - are SBCs a response to a division of responsibilities in a network operator? Is the problem that we don't have policy worked out? Somebody has to enforce policy, especially in the media, so the media has to go through a policy enforement point.
James - but RSVP has provided "IP sessions" between hops for years?
Think of the problem in two parts - end-to-end and in-the-middle - but RSVP does exactly this. It's old, but being constantly renewed - Jonathan - this discussion is out of scope for now, we'll have it later.
Soliman - SBC is important tool for billing a call.
Per-session rate-limiting? Falls under policy enforcement, discussed previously.
Andew - corporate policy policement don't even trust other people inside the corporation. Their job is to "get in the way".
Ben - it's frustrating when we fail in a technology because policies are inconsistent within a "policy domain". But we're not relying on MIDCOM-aware firewalls, we're deploying a new box.
Francois - Is anything actually broken here, or are people just deploying things? What's being deployed may not be the best solution, but we need to gather requirements and look at problems first.
Andrew - what are the categories of problems here? Mostly on the list so far, although we have a few new ones tonight.
Christian - ETSI is using these ideas for UNI-NNI now - NAT-PT, IPv4-IPv6 interworking, QoS marking, policy enforcement, metering.
Martin - SBCs don't have a killer capability, but they have a lot of functions in one box - lower operational costs.
Henry - two kinds of SBCs, one from service providers and one from customer (may not actually be called an SBC, and may span other services as well). Each wants to bypass the other.
We're talking about business relationships, not just technical problems, right?
It's not just enforcement, it's also about expectations - as long as we're not peer-to-peer, we can't tell customers anything about why they experienced problems, we can't prove "it left here OK", and we have to pay credits when we can't figure out problems called by other people.
Henry - isn't bandwidth and trust the solution (we all chuckled).
Jim - Legal intercept, codec normalization, stripping video codecs for some networks,
Control of Layer two QoS - MPLS, VLAN tags, etc.
Brian - I hate "controller" - some of these functionalities are monitoring, not controlling. Also includes DSCP marking, etc.
Cullen - we have studied the digit-stripping before (as part of 3PCC).
Spencer - are we going to talk about problems that appear to result from introduction of SBCs? Probably another meeting.
This is like a mail relay - SBCs have the same requirements as mail relays from IT groups.
Identfying monitoring and controlling matters - we should look at controlling aspects of SBCs.
On monitoring - it's a good thing. Operators don't know that things are fine, what's going on. Not saying SBCs are the right answer, but monitoring is one justification for installing SBCs.
"SBCs are the Halloween loot bag of applications" - the problem we're really solving is service normalization. Jonathan - can we drill down a bit more here?
Heshem - what's happening to SIMPLE requrirements? Do these solutions really work for very large networks? (Out of scope)
Ed - VLAN tagging - twenty service providers have told me they want MPLS tagging - SBCs can make associations between VLAN QoS bits and ToS bits, etc.
If we're traversing a NAT, we have the usual problems with incoming NAT traversal, etc., right?
The number of SBCs a carrier deploys depends on the number of customers, right?
We're getting the same requirements coming up for different problems - what's going on here? Is it just traversing a trust boundary and setting off a lot of problems as a result?
Henry - large backbone providers have been peering for years, with absolutely no loss, no cash changing hands, and they just exchange routes and it works. Why does the peering model for one application have to be so different? - a great question, is there an answer?
Jonathan - the business relation involves cash changing hands now, and that matters.
Jonathan - "protocol repair" - is this a real consideration? are there more details?
Cullen - some things are inherently hard to do. What about mid-point encryption, for instance?
Gonzalo - is turning other protocols into SIP "protocol repair"?
Ben - I'm getting hit every day with a new customer with a new kludge to solve some perceived problem, and the kludges won't interoperate.
... and there are the people who implemented expired drafts, and ...
We're also stripping information at boundaries, or adding required information at boundaries.
We're getting large single-vendor islands that don't interoperate. We're also seeing business policies that don't line up with equipment capabilities.
We have two levels of overload protection - signaling and media. We've dabbled with solutions, and this is far more than a perimeter problem.

Summary

Would like to see this work move forward, would like to turn notes into a requirements document, do an analysis, look at pros and cons, then focus on what gets broken by these approaches. Do people agree?
Keith - look at 3GPP R5 requirements draft! At least some of these requirements are already there.
Need to look at coupling between signaling and media.
Is SIPPING the right place for this? It's not just SIP, right?
The ADs will find a home for this work if people want to do it.
How do we process the requirments? Especially if we think we've solved them already? How do we tell people not to rehash these problems once a year?
A lot of these problems are at intersections - between signaling and media, for instance.
Brian - we need the requirements published, we need a BCP for the solutions that exists. We go wrong most often when we're in corners.
Dean - should we look at a survey document first, and then look at requirements document? Use cases, scenarios...
What mailing list? Starts in SIPPING, at least an announcement.
VoIP Peering would also be interesting to providers in the room.
3G already has an architecture - communications with other organizations.
Spencer - we probably need a terminology effort, too.