Columbia - Verizon Research Secure SIP: Scalable DoS Prevention Mechanisms for SIP-based VoIP Systems, and Validation Te

1. Columbia - Verizon ResearchSecure SIP: Scalable DoS Prevention Mechanisms for SIP-based VoIP Systems, and Validation Test Tools Gaston Ormazabal Verizon Laboratories March 12, 2014

2. Agenda A successful collaboration Verizon and CATT Professor Schulzrinne - three year program Project Overview Background, Research Focus, and Goals DoS VoIP Threat Model DoS Detection and Mitigation Strategy DoS Validation Methodology - DoS Automated Attack Tool Value to Verizon Intellectual Property/Technology Licensing Next Steps Conclusions

3. Verizon – CATT Program Collaboration between Verizon and Center of Advanced Technology Telecommunications Verizon PI: Gaston Ormazabal CATT Columbia University PI: Prof. Henning Schulzrinne Graduate Students Currently Milind Nimesh Previously Sarvesh Nagpal, Eilon Yardeni New York University Polytechnic Institute

4. Background & Research Focus SIP is the VoIP protocol of choice for both wireline and wireless telephony Control protocol for the Internet Multimedia Systems (IMS) architecture VoIP services fast becoming attractive DoS and ToS targets DoS attack traffic traversing network perimeter reduces availability of signaling and media for VoIP Theft of Service must be prevented to maintain service integrity Reduces ability to collect revenue and provider’s reputation both are at stake Attack targets SIP infrastructure elements (proxy, softswitch, SBC, CSCF-P/I/S) End-points (SIP phones) Supporting services (e.g., DNS, Directory, DHCP, HSS, DIAMETER, Authorization Servers) Verizon needs to solve security problem for VoIP services Protocol-aware application layer gateway for RTP SIP DoS/DDoS detection and prevention for SIP channel Theft of Service Architectural Integrity Verification Tool Need to verify performance & scalability at carrier class rates Security and Performance are a zero sum game Columbia likes to work on real life problems & analyze large data sets Goal of improving generic architectures and testing methodologies Columbia has world-renowned expertise in SIP

5. Goals Study VoIP DoS and ToS for SIP Definition – define SIP specific threats Detection – how do we detect an attack? Mitigation – defense strategy and implementation Validation – validate our defense strategy Generate requirements for future security network elements and prototypes Share these requirements with vendors Generate the test tools and strategies for their validation Share these tools with vendors

6. Approach Definition Detection Mitigation Validation

7. VoIP Threat Taxonomy Scope of our research - 2007 Scope of our research - 2006 *- VoIP Security and Privacy Threat Taxonomy, VoIP Security Alliance Report, October, 2005 (http://www.voipsa.org)

8. Denial of Service & Theft of Service Denial of Service – preventing users from effectively using the target services Service degradation to a “not usable” point Complete loss of service Distributed Denial of Service attacks represent the main threat facing network operators* Most attacks involve compromised hosts (bots) botnets sized from a few thousands to over a million 25% of all computers on Internet may be botnets Theft of Service – any unlawful taking of an economic benefit from a service provider With intention to deprive of lawful revenue or property *- Worldwide ISP Security Report, September 2005, Arbor Networks *- Criminals 'may overwhelm the web', 25 January, 2007. BBC

9. SIP DoS Attack Taxonomy DoS Implementation flaws Application level Flooding

10. DoS Implementation Flaws Vulnerability target origin Different levels of the network protocol stack Underlying OS/firmware Result Excessive consumption Memory Disk CPU System reboot or crash Potential for TOS Attacker sends carefully crafted packet(s) to exploit a specific implementation flaw

11. DoS Application Level Attacks Registration Hijacking Attacker registers his device with another user's URI Call Hijacking Attacker injects a “301 Moved Permanently” message to an active session Amplification attacks Attacker creates bogus requests with falsified Via header field that identifies a target host UAs/proxies generate a DDoS against that target A feature of SIP is manipulated to cause a DoS attack

12. DoS Application Level Attacks Session teardown attacks Attacker spoofs a BYE message Injects it to an active session Tears down the session Tricks billing server to stop billing, call continues Modification of media sessions Attacker spoofs re-INVITE messages causing QoS reduction Media redirection Security attributes modification Media streams attacks Attacker injects spoofed RTP packets with high SEQ numbers into the media streams Changes the play-out sequence

13. DoS Flooding Attacks IP variants UDP floods ICMP echo attacks SYN floods VoIP variants Floods of INVITE or REGISTER messages Cause excessive processing at a SIP proxy Floods of RTP Cause excessive processing at Media Gateway Requires more resources from the attacker Harder to defend against Even the best maintained networks can become congested Attacker floods a network link or overwhelms the target host

14. Goals Definition Detection Mitigation Validation

15. Mitigation Strategy Implementation flaws are easier to deal with Systems can be tested before used in production Systems can be patched when a new flaw is discovered Attack signatures can be integrated with a firewall Application level and flooding attacks are harder to defend against SIP infrastructure element defense Commercially available solutions for general UDP/SYN flooding but none for SIP  Address application level and flooding attacks specifically for SIP

16. Strategy Focus VULNERABILITY : Most security problems are due to: flexible grammar  syntax-based attacks Plain text  interception and modification SIP over UDP  ability to spoof SIP requests Registration/Call Hijacking Modification of Media sessions SIP ‘Method’ vulnerabilities Session teardown Request flooding Error Message flooding RTP flooding STRATEGY: Two DoS detection and mitigation filters SIP: Two types of rule-based detection and mitigation filters Media: SIP-aware dynamic pinhole filtering Application Level Flooding

17. Previous Work on SIP DoS Implemented a large scale SIP-aware firewall using dynamic pinhole filtering First-line of defense against DoS attacks at the network perimeter Only signaled RTP media channels can traverse it End systems are protected against flooding of random RTP The RTP pinhole filtering approach is a good first-line of defense but… The signaling port (5060) is still subject to attack on the signaling infrastructure  hence SIP specific filtering was implemented for the first time

18. VoIP Traffic Attack Traffic Mitigation Solution Overview Untrusted Untrusted Trusted Trusted Filter II Filter I Filter I Filter II sipd sipd DPPM DPPM SIP SIP SIP SIP SIP SIP RTP RTP RTP RTP

19. SIP Detection and Mitigation Filters Authentication Based - Return Routability Check Require SIP built-in digest authentication mechanism Authentication with shared secret Filter out spoofed sources Method Specific Based – Rate Limiting Transaction based Thresholding of message rates INVITE Errors State Machine sequencing Filter “out-of-state” messages Allow “in-state” messages Dialog based Only useful in BYE and CANCEL messages Dynamic Pinhole Filtering for RTP Only signaled RTP media channels can traverse perimeter Obtain from SDP interception End systems are protected against flooding of random RTP

20. CloudShield CS-2000 System 10/100/1000 10/100 0 1 2 ASM 1000 1000 Backplane 4 3 Gigabit Ethernet Interconnects D0 D1 D0 D1 P0 P0 DPPM Intel IXP 2800 DPPM Intel IXP 2800 E1 E1 E2 E2 F0 C3 C4 F0 C3 C4 System Level Port Distribution Application Server Module Pentium 1GHz

21. INVITE ACK Compute response = F(nonce, username, password, realm) Authentication: compute F(nonce, username, password, realm) and compare with response SIP Digest Authentication User Agent Client (UAC) Proxy Server Generate the nonce value 407 Proxy Authentication Required (nonce, realm..) nonce – a uniquely generated string used for one challenge only and has a life time of 60 seconds INVITE (nonce, response…)

22. SIP Digest Authentication Statistics Digest authentication accounts for nearly 80% of processing cost of a call for a stateless server 45% of a call for a stateful server* Additional cost 70% for message processing 30% for authentication computation (hashing)* * SIP Security Issues: The SIP Authentication Procedure and its Processing Load, Salsano et al., IEEE Network, November 2002

23. Return-Routability Implementation Succeeds INVITE sip:test1@cs.columbia.edu SIP/2.0 Via: SIP/2.0/UDP 128.59.21.70:5060 Max-Forwards: 70 From: sip:test5@cs.columbia.edu To: sip:test1@cs.columbia.edu Contact: sip:test5@128.59.21.70:5060 Subject: sipstone invite test CSeq: 1 INVITE Call-ID: 1736374800@lagrange.cs.columbia.edu Content-Type: application/sdp Content-Length: 211 v=0 o=user1 53655765 23587637 IN IP4 128.59.21.70 s=Mbone Audio t=3149328700 0 i=Discussion of Mbone Engineering Issues e=mbone@somewhere.com c=IN IP4 128.59.21.70 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 INVITE sip:test1@cs.columbia.edu SIP/2.0 Via: SIP/2.0/UDP 128.59.21.70:5060 Max-Forwards: 70 From: sip:test5@cs.columbia.edu To: sip:test1@cs.columbia.edu Contact: sip:test5@128.59.21.70:5060 Subject: sipstone invite test CSeq: 3 INVITE Call-ID: 1736374800@lagrange.cs.columbia.edu Content-Type: application/sdp Content-Length: 211 Proxy-Authorization: Digest username="anonymous", realm="cs.columbia.edu", nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=", uri="sip:test1@cs.columbia.edu", response="0480240000edd6c0b64befc19479924c", opaque="", algorithm="MD5" v=0 o=user1 53655765 2353687637 IN IP4 128.59.21.70 s=Mbone Audio t=3149328700 0 i=Discussion of Mbone Engineering Issues e=mbone@somewhere.com c=IN IP4 128.59.21.70 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 127.0.0.1:7898 From: sip:test5@cs.columbia.edu To: sip:test1@cs.columbia.edu; tag=2cg7XX0dZQvUIlbUkFYWGA Call-ID: 1736374800@lagrange.cs.columbia.edu CSeq: 1 INVITE Date: Fri, 14 Apr 2006 22:51:33 GMT Server: Columbia-SIP-Server/1.24 Content-Length: 0 Proxy-Authenticate: Digest realm="cs.columbia.edu", nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=", stale=FALSE, algorithm=MD5, qop="auth,auth-int" INVITE INVITE INVITE, Proxy-Authorization INVITE 407 Needs Auth Add Filter (128.59.21.70, ”nonce”) Remove Filter (128.59.21.70, ”nonce”) 407 Needs Auth INVITE, Proxy-Auth Untrusted Trusted DPPM sipd SIP UA NPU CAM RAM IP 128.59.21.70 (128.59.21.70, nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=")

24. INVITE INVITE INVITE 407 Needs Auth Add Filter (1.2.3.4,”nonce”) 407 Needs Auth Return-Routability Implementation Fails Untrusted Trusted DPPM sipd SIP UA NPU X CAM RAM IP 1.2.3.4 (1.2.3.4, nonce="6ydARDP51P8Ef9H4iiHmUc7iFDE=")

25. SIP Session Analysis A call contains one or more Dialogs A Dialog contains one or more Transactions Request/response Typically 2 in case of an INVITE-200 OK & BYE-OK type of session Transactions are of two types Client INVITE Transactions Non-INVITE Transactions Server INVITE Transactions Non-INVITE Transactions SIP sessions/calls can be broken down to 4 levels of granularity

26. Dialogs and Transactions in SIP

27. Level Identifiers Dialog Level A Dialog is identified by The “Call-ID” field The “From” Tag The “To” Tag Rate-limiting at Dialog level is coarser  not applied to keep state information Transaction Level A Transaction is identified by The "Branch" parameter of the Via header The "Method" name in the CSeq field Rate-limiting is more refined and can pinpoint to more specific parameter thresholds  more effective to keep state information The Transaction-ID and Dialog-ID are generated by applying CRC-32 on a collection of the above mentioned fields. The unique CRC-32 Hash generated is used as an index in the CAM tables

28. Method Specific Filtering INVITE Filter redundant INVITE messages by looking up its Transaction-ID and rejecting if its Transaction-ID already exists in State tables. Responses 100 Trying 180 Ringing 200 OK Errors (300 – 600) Out-of-State Sequence of unexpected messages This approach involves defense against specific method vulnerabilities

29. Transaction Filtering Rate limit messages based on expected Transaction traffic: 1 INVITE per transaction 1 (or more) 100 Trying per transaction 1 (or more) 180 Ringing per transaction 1 200OK per transaction 1 ACK per transaction N (based on testing) errors per transaction Error status message rate limiter implemented as high-speed counters in SRAM with granularity of 1 second Rate limits error status messages within the context of a valid transaction 29

30. SIP Message Relationships CAM database has very low latency lookups Aged lookup tables implemented to track dialog and transaction relationships Message lookup tables Dialog-ID Table Transaction-ID Table Messages Identified by Type and Code Type: Request or Response Code: Request Method or Response Status Code Dialog ID Transaction ID 30

31. Transaction Filtering For every new SIP request message received, a Transaction-ID (TXNID) is created TXNID is a 32 bit integer calculated by HASH (Top Via: BranchID, CSEQ Command Value) TXNIDs are stored in a different CAM table (from pinholes and nonces) If TXNID is duplicate, drop the packet “Ideally” only one SIP request message allowed per TXNID Binary switch Retransmission of same request multiple times require a finite retransmissions window 5 packets in current network set up Should be settable for more complex networks Optimization to reduce false positives If TXNID is not duplicate, then go on to next step When new subsequent status messages are received: If status message record is valid, request accepted If status message record is bogus, packet dropped Additional check rate of requests per transaction per second not to exceed a selected finite number (6), else packet dropped

32. SIP Transaction State Validation Makes an entry for first Transaction Request and logs subsequent status messages Logs all messages on per transaction basis Use of wild cards in regular expression syntax All permutations of allowed states validated in a single operation Received packet is added to status messages table for original Transaction If received status message fits valid state pattern, it is accepted Messages resulting in invalid state pattern are dropped and also removed from transaction message log e.g.: the sequence INVITE, 100, 180, 200, 180, 200 causes filter to only allow INVITE, 100, 180, 200, and 180/200 is struck out as 180 is out of state Transaction state is rolled back to the last known good state Overlays on top of other filtering mechanisms

33. SIP Transaction State Validation Request Message Response Message Response Message Response Message Response Message Transaction ID Regular Expression Engine Transaction Message Code Log 0 1 2 3 4 5 32 INVI _100 _180 _180 _200 Regular Expression List ----------------------------------------------------------- INVI(_100)*?(_180)*?_200{0,1}?(\x00){4}

34. Firewall Components Part of SIP-proxy Executed in the Linux Control Plane • Static Filtering • Filtering of pre-defined ports (e.g., SIP, ssh, 6252) • Dynamic Filtering • Filtering of dynamically opened RTP ports • Filtering of nonce and method redundancy • Switching Layer • Perform switching between the input ports • Firewall Control Module • Intercept SIP call setup messages • Get nonce from 407 Need Auth • Get RTP ports from the SDP • Maintain call state • Firewall Control Protocol • The way the Firewall Control Module talks with the firewall • Push filter for SIP UA authentication challenge (with nonce) and media ports • Push dynamic table updates to the data plane • May be used by multiple SIP Proxies that control one or more firewalls Firewall Data Plane Execution

35. Integrated DDOS andDynamicPinhole Filter CAM sipd Dynamic Table SIP SIP DDOS CAM CAM DDOS Table Static Table Outbound Inbound Linux server ASM DPPM FCP/UDP Lookup Switch Drop

36. Goals Definition Detection Mitigation Validation

37. Method-based SIP DoS Attack Scenarios Flood of Responses Flood of Requests Flood of Out-of-State

38. Integrated Testing and Analysis Environment Legitimate Loaders SIPUA/SIPp Call Handlers SIPUA/SIPp Attack Loaders SIPStone/SIPp GigE Switch GigE Switch Controller secureSIP Firewall SIP Proxy

39. Test Tools SIPp, SIPStone, and SIPUA are benchmarking tools for SIP proxy and redirect servers Establish calls using SIP in Loader/Handler mode A controller software module (secureSIP) wrapped over SIPp/SIPUA/SIPStone launches legitimate and illegitimate calls at a pre-configured workload SIPp Robust open-source test tool / traffic generator for SIP Customizable XML scenarios for traffic generation 5 inbuilt timers to provide accurate statistics Customized to launch SIP DoS attack traffic scenarios designed to cause proxy to fail SIPStone Continuously launches spoofed calls which the proxy is expected to filter For this project enhanced with: Null Digest Authentication Optional spoofed source IP address SIP requests SIPUA Test Suite Built-in Digest Authentication functionality Sends 160 byte RTP packets every 20ms Settable to shorter interval (10ms) if needed for granularity Starts RTP sequence numbers from zero Dumps call number, sequence number, current timestamp and port numbers to a file

40. secureSIP Controller Controller Automated Web-based Control Software run on SUN (Linux) box Connects to the Pair of End Points (Loaders and Handlers) Supplies external traffic generation over Private Channel (6252) Launches attack traffic Changes type of traffic on the fly External stress on SUT SIPp in Array Form supplies traffic from 16 SUN (Linux) boxes in various configurations for SIP DoS experiments SIPUA in Array Form supplies traffic from 16 SUN (Linux) boxes for pinhole experiments Results Analyzer Gathers, analyzes and correlates results Handler/Loaders update results to database in real-time Controller analyzes results from databases and aggregates them to get the number of initiated and torn-down calls and their rates

41. secureSIP Control Architecture

42. secureSIP Test Results for DoS & Pinholes SIP DoS Measurements(showing max supported call rates) Dynamic Pinhole

43. The Bigger Picture - Columbia VoIP Testbed Columbia VoIP test bed is collection of various open-source, commercial and home-grown SIP components provides a unique platform for validating research Columbia-Verizon Research partnership has addressed major security problems signalling, media and social threats Researched DoS solutions verified against powerful test setup at very high traffic rates ToS successfully validated integrity of different setups of test bed

44. Value to Verizon Enhanced VoIP security via standards and vendor involvement Columbia requirements valid for VoIP, Presence and Multimedia architectures Rolled the requirements and lessons learned into the Verizon security architecture and new element requirements database for procurement Working with Verizon vendors to mitigate exposures Setup “one-of-its-kind” laboratory facilities for VoIP security evaluations and product development At Columbia, prototype rapid development incubator At Verizon, Columbia/Verizon collaborative test tools set up for a more realistic complex IP-routed laboratory environment Intellectual Property with Six Patent Applications Taken research quickly into marketplace with rapid commercialization Licensing Agreement with equipment manufacturers Several vendors interested Exclusive vs. Non-exclusive Verizon Intellectual Property contact: Gwen Thaxter (gwen.thaxter@verizon.com, 845-620-5156)

45. Intellectual Property - Patent Applications “Fine Granularity Scalability and Performance of SIP Aware Border Gateways: Methodology and Architecture for Measurements” Inventors: Henning Schulzrinne, Kundan Singh, Eilon Yardeni (Columbia), Gaston Ormazabal (Verizon) “Architectural Design of a High Performance SIP-aware Application Layer Gateway” Inventors: Henning Schulzrinne, Jonathan Lennox, Eilon Yardeni (Columbia), Gaston Ormazabal (Verizon) “Architectural Design of a High Performance SIP-aware DOS Detection and Mitigation System” Inventors: Henning Schulzrinne, Eilon Yardeni, Somdutt Patnaik (Columbia), Gaston Ormazabal (Verizon) “Architectural Design of a High Performance SIP-aware DOS Detection and Mitigation System - Rate Limiting Thresholds” Inventors: Henning Schulzrinne, Somdutt Patnaik (Columbia), Gaston Ormazabal (Verizon) “System and Method for Testing Network Firewall for Denial of Service (DoS) Detection and Prevention in Signaling Channel” Inventors: Henning Schulzrinne, Eilon Yardeni, Sarvesh Nagpal (Columbia), Gaston Ormazabal (Verizon) “Theft of Service Architectural Integrity Validation Tools for Session Initiation Protocol (SIP) Based Systems” Inventors: Henning Schulzrinne, Sarvesh Nagpal (Columbia), Gaston Ormazabal (Verizon)

46. Publications, Presentations, Recognition Importance of rapid dissemination of results in industry and academia For knowledge diffusion and ubiquity among research practitioners For PR reasons (licensing agreements and potential sales) Presentation at NANOG 38 – Oct. 10 2006 (HS/GO) Paper published in NANOG 38 2006 Proceedings - “Scalable Mechanisms for Protecting SIP-Based VoIP Systems” Made a headline in VON Magazine on October 11, 2006: http://www.vonmag.com/webexclusives/2006/10/10_NANOG_Talks_Securing_SIP.asp Presentation to at Global 3G Evolution Forum – Tokyo, Japan, Jan. 2007 (GO) Presentation/demo at IPTComm 2007 – New York City, July, 2007 (GO) Presentation at OSS/BSS Summit – Tucson, AZ, September, 2007 (GO) Presentation at Columbia Science and Technology Ventures Symposium: “From Signal to Information Displayed in a Wireless World”, April 2008 (HS/GO) Presentation at IPTComm 2008 – Heidelberg, July, 2008 “Secure SIP: A scalable prevention mechanism for DoS attacks on SIP based VoIP systems” (GO) Presentation at IIT VoIP Conference and Expo IV – Chicago, October, 2008 (GO) Paper published by Springer Verlag - “Principles, Systems and Applications of IP Telecommunications” in October 2008: http://www.springerlink.com/content/r5t1652v3572/ Work incorporated in a new Masters level course on VoIP Security taught at Columbia since Fall 2006, every year COMS 4995-1: Special Topics in Computer Science : VoIP Security (HS) CATT Technological Impact Award - 2007 Invited presentation at FBI-sponsored International Conference on Cyber Security –”A Global Solution to Emerging Cyber Threats”, New York City, January, 2009: http://www.iccs.fordham.edu/program.htm

47. Next Steps for Verizon New vulnerability require a new mitigation technology for VoIP products VoIP should not be deployed without protection SIP proxies are vulnerable to crash Attack tool is easy to build and use Carriers (e.g., Verizon) will need new network elements RFP will include these requirements Vendors must have a ready solution Conversion of research into a product that carriers can use Need to determine optimal architecture for DoS prevention functionality for VoIP Security vs. Performance Hardware vs. Software Implementation Proxy/Softswitch (SW) SBC or New network element (HW/SW), Router? Use internally (protect VZ Network) Use externally (sell new security services to large customers) Get other companies interested to synergize resources and share results

48. Next Steps for Verizon Cisco has just joined project funding research at NYU Polytechnic Institute to develop hardware prototype Objective is to research the optimal hardware platform to implement Columbia-Verizon SIP algorithms Use Cisco experimental cards that will eventually become router blades Continue relationship with Columbia Cisco is funding maintenance of the Verizon testbeds For further research in distributed computing and traffic generation enhancements To assist NYU Poly in testing and validation of new prototype against previous benchmarks To assist in eventual product development during product testing cycle Feedback loop of research and product cycle Other research in related areas Proposal to study SRTP/RTSP What can we do to make the working relationship even more productive? Have the synergistic combination of both CATT components (NYU Polytech and Columbia) and two major industry players (Cisco and Verizon) A model worth emulating! 48

49. Potential Value to Cisco New vulnerability require a new mitigation technology for VoIP products Verizon and other carriers will need new network elements Eventually an RFP will include these requirements Vendors must have a ready solution Incorporation of new technology/functionality into Cisco products, e.g., Service Edge Routers (e.g., 6909/7609) Enterprise Routers (e.g., 4000 series) Testbed support for product development Setup unique laboratory facilities for VoIP security evaluations and product development testing In Columbia, prototype rapid development incubator In Verizon, incorporated Columbia/Verizon collaborative test tools for a more realistic complex IP-routed laboratory environment 49

50. Potential Value to Cisco Softswitch Platform SBC AS ALF OLT Phone ONT GWR Verizon IP/Data Network SIP1 SIP2 IDP VoIP Server Private IP Network Enterprise LAN • Typical Verizon VoIP wireline architecture • Possible use in wireless VoIP architectures • LTE plan contemplates migration to SIP 50