Columbia Verizon Research Security: SIP Application Layer Gateway

1. Columbia Verizon Research Security:SIP Application Layer Gateway Eilon Yardeni Columbia University Gaston Ormazabal Verizon Labs

2. Agenda • Team • Project Overview • Background • What is the Problem • Goals • Technical Overview • Hardware Platform • Software Developed at Columbia • Integrated Testing and Analysis Tool • Large Scale Testing Environment • Conclusions

3. Verizon Stu Elby, VP Architecture Jim Sylvester, VP Systems Integration and Testing Gaston Ormazabal Columbia Prof. Henning Schulzrinne Jonathan Lennox Kundan Singh Eilon Yardeni Team

4. Background • Columbia likes to work in real life problems and analyze large data sets with the goal of improving generic architectures and testing methodologies • Columbia has world-renowned expertise in SIP • Verizon needs to solve a perimeter protection problem for security of VoIP Services • Protocol Aware Application Layer Gateway • Verizon needs to build a high powered test tool to verify performance and scalability of these security solutions at carrier class rates • Security and Performance are a zero sum game

5. What is Dynamic Pinhole Filtering • SIP calls are stateful • RTP media ports are negotiated during signaling, assigned dynamically, and taken down • SIP signaling is done over a static port:5060 • INVITE message contains an SDP message indicating the caller’s incoming media port (e.g., 43564 ) • Response 200OK has SDP with the callee’s incoming media port • Each port creates a pinhole in firewall • Pinholes are kept open only until a BYE message signals closing of both pinholes • Firewall must keep a state table with all active pinholes to check if an arriving RTP packet can enter through an open pinhole, otherwise drop packet

6. INVITE sip:user1@proxy.com SIP/2.0 200 OK From: <sip:user2@loader> From: <sip:user1@handler> c=IN IP4 128.59.19.163 m=audio 43564 RTP/AVP 0 c=IN IP4 128.59.19.162 m=audio 56432 RTP/AVP 0 Example of Dynamic Pinhole Filtering SIPUA User1 SIPUA User2 CAM Table 128.59.19.163:43564 128.59.19.163:56432

7. Project Goals • Program SIP based dynamic pinhole filtering in a parallel processing hardware platform • Build an integrated testing and analysis tool that will validate functionality and performance of above device at carrier-class rates • Tool will provide automation of testing (script based) • Apply testing tool to evaluate several Session Border Controllers on behalf of Verizon • Perform comparative analysis of architectural models and develop architectural improvements • Generalize testing methodology

8. Applicability to Columbia • Hands on experience with SIP Application Layer Gateways • Experience some SIP security related challenges • Experiment with carrier class traffic and scale models • Hands on experience with a state-of-the-art programmable packet processing hardware • Enhance Columbia’s SIP Proxy with Firewall Control Proxy capabilities • Formalize security benchmarking methodology for SIP ALGs

9. Applicability to Verizon • Verizon needs this functionality to perform at high rates for use: • In the protection of highly valued network assets • Session Border Controllers for Packet Telephony • In the provision of security services to Enterprise customers for revenue • VADS (SIP Application Layer Gateway) • Verizon needs to verify in the lab the performance and scalability of this technology prior to introduction in the network

10. Deep Packet Processing Module (DPPM) • Executes Network Application Inspecting and Controlling Packet Data • Real-Time Silicon Database (128 bits wide X 512K long) and Unstructured Packet Processing • CAM technology • Single or Dual DPPM Configurations for HA, Performance or Multiple Use • Physical Connectivity: Gigabit Ethernet and OC-3/OC-12/OC-48 POS Auxiliary Slots Future use for • HDD Module • Telemetry Inputs/Outputs • Optical Bypass/HA Module Application Server Module (ASM) • Hardened Linux Infrastructure • Hosts Analysis Applications • Network Element Management(Web, CLI, SNMP, ODBC) • Mandatory Access Control CS-2000 Physical Architecture

11. CloudShield Application Platform • Applications written in RAVE and “pushed” to DPPM • Dynamic Pinhole Implementation • RAVE based • Complex logic such as SIP call processing is difficult to implement in Regular Expressions (Regex) • Support only a “thin” SIP functionality • SIP Proxy controlling the DPPM (Midcom-like solution) • Introduce SIP Proxy - DDPM data exchange problem • Solved by using a Firewall Control Protocol • Columbia developed a breakthrough solution that allowed to use SIP Proxy with performance equal to the “thin” SIP-RAVE • Maximized the use of RAVE • Use full SIP proxy functionality

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

13. Programmed in RAVE Executed in the DPPM Part of SIP-proxy Executed in the Linux Control plane Columbia Developed Modules Software Modules • Static Filtering • Filtering of pre-defined ports (e.g., SIP, ssh) • Dynamic Filtering • Filtering of dynamically opened ports (e.g., RTP) • Switching Layer • Perform switching between the input ports • Firewall Control Module • Intercept SIP call setup messages • Get RTP ports from the SDP • Maintain call state • Firewall Control Protocol • The way the Firewall Control Module talks with the CloudShield • Push dynamic table updates to the data plane • Could be used by multiple SIP Proxies that control one or more CloudShield firewalls

14. SIP FCP/UDP Outbound Inbound Columbia Modules Diagram Linux server sipd Firewall Control Module Control Messages Proxy CAM CPOS Static Dynamic Table Table Lookup Switch Drop

15. Integrated Testing and Analysis Tool Intelligent Integrated End Point Tool Components • SIPUA Test Suite • Loader • Handler • Scanning Probes • nmap • Automated Script based Control Software • Timing Devices • Data Analysis Module • Analyze handler’s file for initial and teardown call delays, • Number of packets dropped before pinhole opening • Number of packets crossing after pinhole closing • Scan results for pinhole coverage • Protocol Analyzer • SNORT • Graphical Displays

16. SIPUA Handler Signaling and Media Generation Integrated Intelligent End Point Untrusted Trusted Control andAnalysis IIEP SUT IIEP Traffic Generator TrafficAnalyzer Port Scanning SNORT Probes Traffic Passed Media Port through Pinholes 4 Scanning/Probing Traffic SIPUA Loader Signaling and Media Generation Timing Synchronization

17. SIPUA Methodology • Loader/Handler • Establishes calls using SIP • Sends 160 byte RTP packets every 20ms • Settable to shorter interval if needed for granularity • Starts RTP sequence numbers from zero • Dumps call number, sequence number, current timestamp and port numbers to a file

18. accept call=1 accept call=2 accept call=3 accept call=4 SIP Proxy invite sip:user1@cloudshield invite sip:user1@cloudshield invite sip:user1@cloudshield invite sip:user1@cloudshield SIPUA Traffic Generator SIPUA Handler SIPUA Loader SIP Proxy

19. Large Scale Integrated Testing and Analysis Environment • Pair of Intelligent Integrated End Points • Generate traffic for detailed analysis • External Traffic Generator • Supplies external stress on SUT • SIPUA in Array Form supplies traffic from an array of 6 computer pairs • Controller • Automated Script based Control Software • Connects to the External Traffic Generation and the IIEP over ssh • Invokes traffic generation • Gathers, analyzes and correlates results • Analyzes handler/loader’s files for initial and teardown call delays • Matches port scanning results with handler’s file

20. External Loaders (SIPUA) External Handlers (SIPUA) Handler IIEP Loader IIEP Controller Testbed Architecture GigE Switch GigE Switch SIP Proxy

21. Problem Definition • Problem parameterized along two independent vectors • Call Rate (calls/sec) • Related to performance of SIP Proxy in Pentium • Concurrent Calls • Related to performance of table lookup in IXP 2800

22. Testing And Analysis Methodology • Generate external load on the firewall • SIPUA Loader/Handler in external load mode • Generates thousands of concurrent RTP sessions • For 30K concurrent calls have 120K open pinholes • CAM table length is 120K entries • Search algorithm finds match in one cycle • When external load is established, run the IIEP analysis • SIPUA Loader/Handler in internal load mode • Port scanning and Protocol analyzer • Increment calls/sec rate • Measure pinhole opening and closing delays • Opening delay data provided in units of 20 ms packets • Closing delay data provided in units of 10 ms packets • Detect pinholes extraneously open

23. Data Results

24. Data Results (2)

25. Benefits to Verizon and Columbia • Technology Transfer to Verizon Labs • Set up a replica of Columbia testbed in Silver Spring VoIP lab for rapid SBC evaluation • Licensing Agreement with CloudShield • Currently negotiating a Royalty Agreement to take technology to market • Intellectual Property • Patents and Publications

26. Technology Transfer • Silver Spring VoIP Lab testbed • Have 12 computer in parallel running SIPUA, SNORT, nmap, protocol analyzers • Set up Controller software • Interoperability testing with local SIP proxy (Broadsoft) • SIPUA can be used for other SIP performance testing with modifications

27. Intellectual Property • Pending 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) • Paper submitted to MASCOTS 2006 • “Large Scale SIP-aware Application Layer Firewall”. • Authors: Henning Schulzrinne, Eilon Yardeni (Columbia), Gaston Ormazabal (Verizon)

28. Conclusions • Have implemented for the first time a SIP ALG that scales up to 30K concurrent calls with 300 calls/sec • This performance should satisfy Verizon “carrier-class” requirements at a reasonable cost • Have proved hypothesis that cpu exhaustion will limit scalability because of degradation in performance • Have constructed a SIP Proxy based model that will permit modularization, • Hence increasing scalability of future architectures • Have built a one of a kind high-powered “black box” testing environment • Will permit Verizon verify this technology for other vendors

29. Back up slides

30. GWC Unsecure signaling protocol Media traffic ACL-secured signaling protocol Public Internet MS20x0 CISCO 6509 PP8600 Pkt Filtering PP8600 Pkt Filtering Juniper M40 CPE/Enterprise Network CPE/Enterprise Network PVG MG9K Verizon Future Security Architecture Verizon Packet Telephony Access/Aggregation Network Call Server Network SIP NGSS Media Proxy H.248 H.248 Shielded CallP VLAN MPCP