Jonathan Rosenberg: Why we are here: SBCs exist, it is best to deal with it now, not in a couple of years in a “son-of-behave” approach. Want to try to understand the problem in advance.
Want to start with requirements of SBC network elements. Not requirements like via stripping or b2bua, which are mechanisms to meet requirements – need higher level requirements.
Want to stay away from solutions and dogma/religion – focus on requirements only.
Start with context setting – what are SBCs being used for today
Ways to categorize problems space
- where they live – for instance on the boarder
o NNI-like interface between service providers
o UNI-like interface between client and service providers
- Functional breakdown
o Thinks like perimeter defense
Jim Hortney Acme Packet
- access control
o White list, black list based on IP address
o Who can get into network for voice services
o Protecting infrastructure of service provider, including proxies, gatekeepers, application servers, media servers
- topology hiding
o using nat techniques
o Don’t expose ip addresses of service providers network elements
o Protect them from being attacked – prevention of denial of service attacks
o route stripping
Ken Fischer – level 3
– consolidation point for advertising of topology to peers and customers
– minimizes number of entry points into the network from a media perspective
– lets carrier change topology without telling peers about all of the changes to the topology
– peers need ip addresses to provision static routes in firewalls
BT
- emphasized Ken’s point
- Different level of security based on the peer
Nextone
- creation of a trust boundary
- boarder access control
o Monitor usage- calls, bandwidth
o SLA management
- Topology hiding
o Via, route, contact, etc
o Routing headers
o Other headers that contain addresses
Rohan
- A lot of source ip address based solutions abandoned because of security concerns so need to understand what the real requirements are.
Ken Fischer
- Might be addressable with a SIP aware firewall
Cullen
- What are the levels of security
- What are the policies that get executed for different levels
BT guy
- Levels of trust
o Very trusted – just need SLA management
o Untrusted – need very high level of security
Jiri Kuthan
- What are the specific scenarios
- What is the managed service
BT guy
- Do not want to manage on services
- Managing the interface between networks – protocol independent
Spencer
- End-to-end security – are we in an end-to-middle world now
- Jonathan
o could be middle-to-middle security for NNI like scenario
o could be end-to-middle for client access control
Ben Campbell
- Generalization to defining policy on the type of peer
- Have an authentication requirement
- Often authentication of previous hop
- Source IP is a risky authentication issue
- Primarily talking about media
Jonathan
- SIP layer has pretty good mechanisms for previous hop authentication – for instance TLS
- RTP does not have this type of capability built in
- Ken Fischer confirmed
???
- Some vendors implement both signaling and media in both, some implement separately, may need a protocol between them if they are separated
- Out of scope for this discussion
- Problems
o Ip addressing
o Transcoding
o Traffic engineering
o Topology hiding
o Regulatory issues
o Billing and accounting
o SLA monitoring
o Silent suppression
o Echo cancellation
o Service level prioritization
Larry - Nextone
- Different kinds of policy
o QoS management/SLA management
§ Based on via or from
- Boils down to two things
o Topology hiding
o Packet inspection
§ For SLAs
o CALEA might
Azita – Cisco
- For packet inspection – why is it session based as apposed to all packets
- Ken – to be able to stop the packets when the session goes away
- Azita – shouldn’t the traffic inspection be better
- Ken – a more general solution would probably be good
Henry – MCI
- Henry is just a messenger J
- People like the SBC for economic reasons
- Its easier to manage customer interfaces on a single or small number of enterprise at a single point instead of at every customer site
Cullen – Cisco
- Are they being used for NAT traversal
- Nextone
o Its an economic way of doing NAT traversal
- Cullen – is it a major driver
- Nextone – yes for now but likely to decrease in need as ICE or other things are deployed.
Spencer
- Is b2bua a requirement
- Jonathan – no, that’s a technique
- Spencer – is it dealing with intercepting media streams
- Jonathan – correct
Miquel Garcia
- We are hearing excuses – only one problem we are solving – giving the service provider the feeling of control
Franscous (sp?) - ???
- Enterprise side has the same problem
o Want to get through NAT/FW without breaking their security
o Solved by passing signaling and media through a single firewall
o Solving routing issues
o Like a funnel in and out of the enterprise
o Protocol repair
o Have case of enterprise SBC talking to carrier SBC
Dean Willis – Cisco
- Very often it is an operational error if anything but SIP or media is going across the network boundary
- Forcing odd ball routing for a service is a use as well – way of controlling the path the path media takes
??? - Polycom
- NAT traversal is first requirement
o Acting as relays for the media
- Control of routing of the packet
- SBCs changing of payload breaks end-to-end security
??? - ???
- Two scenarios in which they are deployed
o Aiding in traversal of enterprise NAT
o SBC acting as the NAT itself
§ Carrier network is all private address space
§ Allows for QOS control
Jim Hortney – Acme Packet
- Single layer 3 device for signaling and media
- Hiding suppliers from customers
o Middle carrier hiding the edge carriers from each other
Andrew Allen - ???
- Emphasized enterprise needs
??? – Nextone
- b2buas are used for topology hiding only
Shi?? – Kahone?? networks
- people want to deploy sip aware firewall
- TLS offloading
- Call gapping on access control
Alan - ???
- it’s a layer 7 thing not a layer 3 thing
- easier to manage with a small number of layer 3 access points
??? – Polycom
- ???Missed the comment
Ben Campbell
- used to get around enterprises where application deployments in enterprises can’t get around enterprise IT group
- political boundary
??? - ???
- Want to be able to trouble shoot calls
o SBC can look at the session for debugging purposes
- 2833 for dtmf on rtp – sbc can pick off dtmp rtp packets and send them to an application
- session admission control
o control how many sessions are coming form different peer networks
- policing per session
??? – nextone
- Service normalization
- Transcoding
- Dtmf
o inband detection of dtmf and forwarding to application server that only understands 2833
o other approach is 2833 packet forwarding
§ Used when application server is not in the media streams
Azita – Cisco
- talking about application trunks
- how do SBCs control routers
o Nextone – for qos reasons
o Qos peering between providers???
Paul K – Cisco
- is this a policy enforcement point?
James Polk
- sessions can be understood using RSVP
??? – Nextone
- Comment on RSVP
o It is end-to-end
o Need to make sure it addresses middle to middle problem
Sherman Mahoney??? - ???
- SBC can do billing
Alan
- Per session rate limiting
- Fraud prevention
Andrew
- To Paul K’s comment – it is a political thing
- Enterprise firewalls don’t trust anyone, inside or outside of the firewall
Ben
- Paul was talking about policy circumvention points, not policy enforcement points
- Policy enforcement defined functions are not sufficient to enforce the policies that need to be enforced
François
- Is there anything broken that needs to be fixed
- Jonathan
o First step is to understand requirements and problems that need to be solved
o Second step is to determine if there is standards activity to address problems
Andrew
- Summary of issue
o QOS
o Firewall
o CAC/policing
Christen - ???
- from contribution at ETSI
o address
o natpt
§ topology hiding
§ ipv4, ipv6
o QOS marking
o Bandwidth limiting
o Metering
??? - ???
- It all comes down to dollars
- Probably not one killer reason to deploy an SBC
- It is a convenient place to put new functionality
Henry
- Two types of SBCs
o External deployed by service providers
§ Because the don’t trust their customers
o Internal – controls voip, web, email, spam filtering, etc
§ Because the enterprise doesn’t trust service provider
o Each is trying to bypass the other policy enforcement point
Azita
- Talking about business relationship
- Point to establish business relationship with the peering entity
Ken
- Also needed for problem resolution when dealing with customer calls
- Way of showing that the peer is responsible for lost or underperforming calls
??? – Acme Packet
- qos reporting
- legal intercept
- codec normalization
o codec stripping
o transcoding
o routing based on codec – i.e. routing video to a different network
??? – Nextone
- there are economic reasons to deploy
Brian Rosen
- Ken’s point isn’t a need to control, but a need to monitor
- SBC handles marking packets based on receiving networks needs
Cullen
- dtmf question is similar to 3pcc solution
???
- do we need another meeting to address issues with SBCs
??? – Polycom
- SBC is like a mail relay
- When it does the relay, it can also do applications also
??? - ???
- monitoring – already a group looking into monitoring
- need to look at controlling aspect
Jiri
- Monitoring topic
o From SIP server perspective it is a good thing to have a monitoring capability
o SBC may be a bad solution
§ Added latency
§ Added management overhead
§ Another point of failure
??? – Nextone
- Comment, SBCs are a “loot bag”
- SBCs are really solving service normalization and service availability
Hashan? - ???
- Not sure anymore what an SBC is
- Sounds like people are doing things that cross many layers
Ed Lauton – Newport
- vlan tagging
- instead of point to point vpns, looking at extending mpls to enterprise
??? – Nextone
- on scale question
o number of SBCs depends on number of customers
Henry
- MCI does a lot of peering despite lack of trust between peering partners
- It works because the peering is done without cash changing hands
- Why can’t the peering for the voice application have to be so different than the peering for the Internet
Jonathan
- Discussion on protocol repair
- Is this a real problem or is it a problem that will go away
- Cullen
o Some things are inherently hard to do – for instance RTP/SRTP
- Kiri – Is translating H.323 to SIP protocol repair – the consensus seemed to be that it is J
- Ben – as a consultant dealing with the issues he is surprised at how big a problem it is.
- Christian – Might not be protocol repair, can do topology hiding
- Alan – interop doesn’t work well between vendor equipment – some cultural business practices
Mike Romalo, Cisco -
- Call gapping, there are solutions for media, is there the same capability at the SIP level
- Jonathan – probably something that needs to be addressed
Next step discussion
Jonathan – proposal for a path forward
- Continue with this process
- Take the notes and build a requirements document from it
- The requirements document would be an input into SIPPING (or other working group)
- Then go through working group process to define the solutions
Keith
- Some of this is already addressed in 3GPP
Steve Donovan
- Is SIPPING the right place
Jon Peterson
- The ADs will find a home for the work
James
- How do we categorize requirements or map them to solutions
- To prevent the multiple solutions being created
Jonathan
- Important part of the process is categorization
Brian
- need requirement doc to be published
- for requirements that have a solution – need a BCP to document these
- need to make sure there is a place for every requirement
Dean
- is requirement document the correct first step
- may want a survey document – more of a use case or scenario document on how SBCs are currently being used.
??? - ???
- request for VoIP peering working group
??? - ???
- Is there communication with other orgs needed to capture these requirements
Spencer
- need to focus on terminology
Gonzalo - Everything will be announced in the SIPPING list