Why Do I Need an SBC


Published on

Avaya Aura® Session Border Controller, powered by Acme Packet, secures the IP border for the real time interactive communications that flow outside your internal network. With Avaya Aura® Session Border Controller, your Unified Communications and Contact Center Solutions can securely leverage SIP, while simultaneously extending the power of the Avaya Aura® architecture throughout your enterprise to realize the true benefits of open standards.

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • SBC Value within the Avaya Aura Architecture As enterprises are moving rapidly to adopt Session Initiation Protocol (SIP) for connection to service providers (SIP Trunks), hosted application providers, extranet partners and remote workers, a common question is: ‘Since the SIP trunk provider already has an SBC in their network, why does a customer of that provider require an SBC on their premise as well ?  SecurityAn enterprise SBC provides essential SIP security regardless of whether the public SIP trunk service is delivered as a dedicated connection from the SIP trunk provider or via a shared MPLS network. VoIP is a service that runs on IP, just like email and web browsing. Enterprises do not rely on their Internet Service Providers to protect those services using a central, communal firewall. An enterprise SBC enforces the customer’s unique VoIP security policies – just like an enterprise firewall does for data – and ensures that any regulatory requirements for data security are met. It provides the enterprise complete network topology hiding, up to Layer 7, meaning all extra-enterprise SIP signaling and RTP media are anchored through the enterprise SBC, mitigating the risk of exposing large ranges of private IP addresses to an externally controlled foreign entity and the associated possibilities of intentional or unintentional (misconfiguration) attack. Unlike an enterprise firewall, an enterprise SBC is specifically designed to parse each SIP message via deep packet inspection and manipulate the SIP headers if necessary to ensure protocol compliant formatting. The SBC is able to enforce signalling rate limiting and media bandwidth policing and reduce the impact of DoS attacks by using dynamic access lists triggered by behavioral analysis of users and traffic.  FlexibilityWithout an enterprise SBC, certain configuration changes may need to be done at the central SBC by the service provider. The service providers network operations processes preclude rapid and frequent changes to the central SBC platform configuration – primarily for stability reasons. Most service providers only offer one enterprise-facing configuration and will not change it. Those who will make changes will only do so after extensive regression testing – and this takes place very infrequently – at most 1 or 2 times a year. This means that it is often very difficult to meet the changing needs of customers and/or meet a customer’s specific needs for interfacing their particular communication infrastructure and associated security policy requirements. By installing an enterprise SBC, the customer’s specific communications requirements can be fully addressed, insulating the service providers SBC from any changes. This means that the specific business needs of the customer can be met in a quick and easy way. Also, any adaptation costs are specific to that customer and do not impact the on-going network operations costs. The enterprise SBC provides an ideal reference interface for network border interoperability testing by normalizing the signaling and RTP streams into the enterprise. Additionally, an enterprise may wish to work with multiple SIP trunk providers. The SBC is an enabler if more than 1 SIP trunk provider is terminating to the enterprise, providing common demarcation point for normalization. Finally, an enterprise’s business requirements, now or in the future, will drive enterprise specific call flows that may not necessarily be supported or directly interoperable with a SIP trunk provider. A premise SBC can be configured to meet an enterprise’s specific requirements.  AccountabilityAn enterprise SBC can generate per-call statistics including QoS measurements for independent SLA monitoring. It can also provide reports on intrusion attempts (IDT) and provide session replication for call recording to meet industry or regulatory requirements. Thus, for these reasons, Avaya strongly recommends deployment of the Avaya Aura Session Border Controller or Acme Packet-branded SBCs within the Avaya Aura architecture.
  • 49% growth in Enterprise SBC slaes between 2008 to 2013 estimated by Infonetics (report was written in late 2007).Infonetics acknowledges the momentum of the SBC toward the enterprise for functions previously only addressed by the SP.Gartner acknowledges security and interoperability advantages to an enterprise SBC.The most interesting statement from Gartner is the last, which highlights the partnership of SBC with a session manager. Avaya is unique in the Enterprise with the concept of a session manager, and its inherent ability to broker applications. This session-based architecture makes the need for an SBC much more prevalent than some of our more traditional competitors. In other words, the Aura architecture is different. And this is why SPs are not seeing the demand for a premise SBC from all Enterprise SIP trunking vendors . . . Yet.
  • Why Do I Need an SBC

    1. 1. Why Do I Need an SBC ?<br />PacketBase, Inc.<br />
    2. 2. MM<br />App<br />App<br />VP<br />App<br />CM<br />Application Platform<br />Application Platform<br />Avaya Aura™<br />Session<br />Manager<br />Avaya Aura™<br />SBC<br />Avaya Aura™ SBC and the Reference Architecture<br />Application<br />MX<br />SystemManager<br />PSTN trunking providers, hosted services, federated partners<br />Media<br />Servers<br />SIP Trunks<br />or<br />Connection<br />SIP Trunks<br />Avaya Aura SBC or<br />Acme Packet SBC<br />SIP<br />Avaya one-X®<br />endpoints<br />Internet<br />Access<br />3rd Party PBXs<br />Avaya CM<br />(branch or <br />standalone)<br />Remote workers via<br />Internet (future)<br />3rd Party<br />endpoints<br />2<br />
    3. 3. Things to think about…<br />Service Providers maximize revenue by designing their network to be highly optimized with minimal maintenance<br />Their SBC’s, Softswitches, and Media Gateways are widely shared resources<br />Unique customer configuration requirements deviate from this theme<br />For SIP Trunks, each Service Provider has explicitly defined User to Network Interface (UNI) requirements<br />The requirements include supported SIP message types requests/responds, methods, formatting, headers, fields, codec’s, QoS markings etc. <br />Within a single Service Provider, the UNI will differ with each unique service offering.<br />Enterprise customers do not subscribe to the same model, instead focusing on implementing solutions that meet customer needs and differentiate their business<br />Traditional demarcation points, i.e. media gateways, no longer act as natural boundaries to enforce expected service provider behaviors and requirements<br />
    4. 4. Why use an SBC?<br />Flexibility<br />Providers layer of independence from Service Provider – allows enterprise to make changes more quickly vs. negotiating / relying on Service Provider if needs change<br />Normalization point for signaling and RTP media streams to multiple SIP stacks in the enterprise <br />Allows for multiple SIP trunk provider access points (now or in future)<br />Support of enterprise-specific call flows that may not be directed supported by SIP trunk provider<br />Security<br />Enforces a customer’s unique security policies <br />SIP trunk provider’s own SBC (if private SIP trunk service) focuses on the provider’s security concerns<br />Complete network topology hiding<br />Addresses set of issues specific to SIP-based communication (deep packet inspection)<br />Accountability<br />Per call status – QoS, SLA monitoring<br />Report on intrusion attempts<br />Session recording<br />4<br />
    5. 5. Analyst View - SBCs and the Enterprise<br />5<br />
    6. 6. The Security Threat - Examples<br />June 2009 – International Phone Fraud Ring busted – Softpedia<br />Eight indicted for stealing calls totaling over 12 million minutes and resulting in phone bills of more than $55 million<br />May 2010 – FBI warns on VoIP attacks<br />TDoS attacks create diversion for information thieves to loot bank account information<br />October 2010 - VoIP Attacks On The Rise! Secure Your VoIP Servers – blog.sipvicious.org<br />Cloud-initiated wave of SIPVicious port 5060 scans lead to €11 million loss<br />December 2010 – Major VoIP Fraud Gang Dismantled in Romania<br />50 individuals used “Zoiper” program to route calls to premium rate numbers through hacked VoIP accounts in exchange for commission<br />6<br />
    7. 7. Gartner – SBC Evaluation Criteria<br />Has been thoroughly tested and documented as an integral part of the enterprise UC solution<br />Has been incorporated into the certification configurations of the enterprise UC solution with the SIP trunk service provider<br />Provides support and maintenance services for UC <br /> Provides a full set of security features, including prevention of DoS and DDoS attacks <br />Source: http://www.gartner.com/technology/media-products/reprints/avaya/vol6/article8/article8.html <br />7<br />
    8. 8. 8<br />Enterprise and contact center security threats<br />Denial of Service<br />Call/registration overload<br />Malformed messages (fuzzing)<br />Configuration errors<br />Mis-configured devices<br />Operator and application errors <br />Theft of service<br />Unauthorized users<br />Unauthorized media types<br />Viruses & SPIT<br />Viruses via SIP messages <br />Malware via IM sessions<br />SPIT – unwanted traffic<br />Enterprise Adoption of Collaboration Tools<br />Source: Nemertes Research<br />Increased usage of collaboration tools<br />means security threats are more of a concern<br />
    9. 9. SBC DoS <br />protection<br />Fraud<br />Access<br />prevention<br />control<br />Service<br />infrastructure<br />Topology hiding<br />DoS<br />& privacy<br />prevention<br />Viruses<br />malware<br />& SPIT<br />mitigation<br />Avaya Aura™ SBC & Acme Packet Net-Net SBC Security Framework <br />SBC DoS/DDoS protection<br />Protect against DoS/DDoS attacks<br />Access control & VPN separation<br />Dynamic, session-aware access control for signaling & media<br />Topology hiding & privacy <br />Viruses, malware & SPIT mitigation<br />Deep packet inspection <br />Encryption and Authentication<br />TLS, SRTP, IPSec<br />Monitoring and reporting<br />Record attacks & attackers<br />Provide audit trails<br />9<br />
    10. 10. GSSCP (Global Service Provider SIP Compliance Program)<br />Program to test and document valid working configurations with SIP trunk providers<br />Tests are tied to 6 defined Avaya reference configurations<br />Avaya has recently published Interoperability Guidelines document <br />SBC testing guidelines<br />Implications of implementing a non-tested configuration<br />3rd party SBC guidelines<br />10<br />
    11. 11. SBC Feature Summary<br />The SBC will provide the interworking function between the Avaya Aura Communication Core and SP specific SIP methods <br />Faster deployment of Avaya Aura solutions at lower risk and cost <br />Easier integration of Avaya Aura with external third-party applications and services <br />The SBC provides DoS (Denial of Service) protection by rate limiting traffic into the enterprise <br />The SBC provides topology hiding for the enterprise infrastructure <br />The SBC will be the anchoring point for in-bound calls and will consume REFER method indications to redirect traffic internal to the enterprise <br />The SBC may need to fork media for recording purposes<br />The SBC may be required to transcode media<br />Reference point for Interop testing with SIP trunk providers<br />11<br />