NG 9-1-1 security: What is a BCF

1. NG 9-1-1 security: What is a BCF

2. Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

3. Topics • What are the features/functions of a BCF? • What does it mean to provide a highly available BCF? • How should the BCF handle overload? • What could DDoS and TDoS do to the ESInet? • Where does NENA place the BCF into the i3 architecture? • Interoperability: Isn’t SIP a standard?

4. Abstract • The BCF (Border Control Function) is an important functional element of the NENA i3 Solution architecture because it provides the first line of defense against deliberate attacks and organic events on the Emergency Services Internet (ESInet.) It is expected that Public Safety Answering Points (PSAPs) will provide a BCF between their internal networks and the ESInet. The BCF is intended to provide secure entry into the ESInet for ingress emergency calls.  This Functional Element ensures the smooth processing of emergency calls/sessions, including signaling protocol normalization and interworking, codec negotiation, support for QoS/priority markings, media proxy, and more.  As such, there are some baseline, minimum features and functions that are required to effectively ensure the smooth, secure operation of NG9-1-1 networks.

5. Background • National Emergency Number Association (NENA) • Sets standards for emergency calls in North America • Next Generation 911 (NG911) project • Complete overhaul of current 911 system • Initial version of the technical standards known as i3

6. What is NG 9-1-1? • IP-based replacement for E911 features & functions • Supporting all sources of emergency access to appropriate public safety agencies • Operating on managed, multipurpose IP-based session delivery networks • Providing expanded multimedia data capabilities for PSAPs and other emergency communications entities

7. IP-based services are easy targets • IP networks are inherently insecure • Developed without security in mind • Organizations rely on IP networks • Multimodal communications difficult to control (BYOD) • Confidential information freely exchanged by users that don’t understand how it is transmitted

8. What are the risks/vulnerabilities? Toll fraud, fuzzing, message floods, session hijacking, eavesdropping, MITM call modification, media injection Buffer overflows, malware, D/DoS, bugs, configuration issues Resource exhaustion, account manipulation, service poisoning UDP/TCP floods, ICMP vectors, fuzzing, D/DoS Physical access compromise, reboot Weak passwords, abuse of services, oversharing, pretexting

9. Threat landscape

10. Denial of Service Many platforms don’t perform well in flooding scenarios They either have a flawed architecture or all attacks are presented to CPU, reducing resources available for system/applications (e.g., SIP) In our experience and field validation, a simple TCP SYN attack or INVITE flood is enough to take down many devices root@bt:# hping3 -S --rand-source --flood -p 5060 <remote_IP> root@bt:# invitefloodeth0 <user> <domain> <remote_IP> <number of invites> Reduced feature “good enough” SBCs work great …until you are under attack!

11. Wasn’t TDM safer? • Eavesdropping, media injection, and caller impersonation is as easyas hooking up a lineman’s test set or “butt set” to wire pairs. • Toll Fraud can be as easy as an open auth code on your PBX or dial-out of voicemail • Physical attacks are always great for DoS, regardless of technology

12. What to do? • Border Control Function (BCF) • Sits between external networks and the ESInet and between the ESInet and agency networks • All traffic from external networks transits a BCF • Acts as a demarc • Comprises several distinct elements pertaining to network edge control and SIP message handling • Border Firewall • Access control • Protect from attacks • Session Border Control • Prevention • Detection • Reaction

13. BCF: features • Border firewall • Session border control • Signaling B2BUA • Media anchoring • Denial of service • Detection/protection • Topology hiding • Signaling normalization • NAPT traversal • IPv4/v6 interworking • Admission control • Encryption anchoring

14. SBC – Session Border Controller • Already protecting live global real-time IP networks • Functional element of BCF • DOS/DDOS protection, overload, resource admission control • SIP normalization/interoperability • Resolving NAT issues • Opening/closing pinholes • B2BUA/topology hiding • IPv4-IPv6 interworking • VPN bridging • Transport and encryption • QoS marking, priority, reporting • Call detail records • Transcoding • Much, much more

15. Additional features of BCF/SBC • Routing and session management • Time-of-day, day-of-week • Cost, carrier • QoS • External policy • Normalization • User-configurable • Codec management • Stripping, reordering • QoS marking • Reporting

16. High availability – vendor dependent • May be limited to media only and not call control or configuration • What good is a call that can’t be put on hold, hung up or transferred? • What’s the use if post-failover routetreatment may be different? • Many cases takes several seconds to fail over all sessions • Which leads to users hanging up • May use a network carrying traffic for state replication vs. dedicated links • Leading to loss in peak periods • Loses CDR info for established calls • First Class HA: • Hitless failover • Media, session, configuration sync • Retention of critical call data • Dedicated, redundant HA com links

17. Placement of BCF in i3, per NENA 08-506