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.
<>This is a symmetrical issue, too. Imagine hourly DHCP
address changes. BT is looking for network management help here.
- 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.