1. 1 Protecting SIP Against DoS An Architectural Approach

2. 2 Motivation ► SIP implementations vulnerable to DoS ► Current solutions placed near destination  But these cannot cope with large attacks ► Need an architectural approach  Detect attack at destination  Block attack close to its sources

3. 3 Basic Architecture ISP A Internet SIP FILTER SIP AGENTS SIP FILTER Legacy ISP B ISP B ISP D SIP FILTER SIP AGENTS Detect attack A filter request A

4. 4 Basic Architecture: Detailed View C1 ISP A (SRC) Internet ISP B (DST) ISF C2 C3 PAPA C = SIP UA ISF = Ingress SIP filter ESF = Egress SIP filter R = SIP registrar P = SIP proxy RARA PAPA RARA ESF C4 Filter Request, send to ISF@domain

5. 5 Basic Architecture: No Proxies C1 ISP A (SRC) Internet ISP B (DST) ISF C2 C3 PAPA RARA PAPA RARA ESF C4

6. 6 Basic Architecture: One Proxy C1 ISP A (SRC) Internet ISP B (DST) ISF C2 C3 PAPA RARA PAPA RARA ESF C4

7. 7 Basic Architecture: Two Proxies C1 ISP A (SRC) Internet ISP B (DST) ISF C2 C3 PAPA RARA PAPA RARA ESF C4

8. 8 SIP ID-spoofing Prevention: Intra-Domain C1 ISP ISF R SIP ID: johnp IP: 10.0.0.100 MAC: 00:00:00:00:00:00 C2 SIP ID: jackh IP: 10.0.0.101 MAC: 00:00:00:00:00:01 C3 SIP ID: eve IP: 10.0.0.102 MAC: 00:00:00:00:00:02 Database:.100 / :00:00.101 / :00:01.102 / :00:02 Database:.100 / johnp.101 / jackh.102 / jillm INTERNET.100 = johnp? YES.100 = eve? NO!

9. 9 SIP ID-spoofing Prevention: Inter-Domain C1 ISP A (SRC) Internet ISP B (DST) ISF C2 C3 PAPA RARA PAPA RARA ESF C4 TLS tunnel ► ESF trusts packets came from ISF (TSL tunnel) ► ESF trusts ISF to ingress filter ► So, ESF can tell packets came from C1, C2 or C3

10. 10 Filtering Protocol ► Detector at destination triggers filter request ► Need to know which SF to send request to  Wait until next packet, record TLS endpoint ► Need to authenticate requests  TLS tunnel takes care of this

11. 11 Attack Detection ► Either at source or destination domain  Destination ► Can detect even very distributed attacks ► State-holding attacks on proxies  Source ► Can prevent spoof-based attacks ► Can detect flooding clients, prevent attack

12. 12 Additional Slides

13. 13 Attacks Prevented by Authentication Mechanism ► BYE attack ► CANCEL attack ► RE-INVITE / UPDATE attacks ► REFER attack (don’t accept from non-tunneled referrers) ► Route-record spoofing (don’t accept from non-tunneled) ► REDIRECT server impersonation, moved permanently ► Reflection, fake Route, Via or Request-URI ► Reflection, spoofed INVITE ► State-holding attack, INVITEs with spoofed SIP IDs

14. 14 Attacks Prevented by Source-Domain Filtering ► Registrar attacks  Flooding  Guessing login/password via brute-force  De-registering entries  Amplification attack, get all current registrations  SQL injection attacks  Registering too many IDs, amp attacks through forking ► Parser attacks  Large header/body  Mismatched Content-Length header to actual length  Malicious re-arrangement of fundamental headers

15. 15 Attacks Prevented by Source-Domain Filtering (ctnd) ► Flooding attacks  SIP Invites  State-holding for proxies, too many sessions ► Proxy attacks  Force look-up of fake DNS names, black-list  Loops through Via header

16. 16 Attacks Prevented by Destination-Domain Filtering ► Distributed Flooding attacks ► State-holding attacks on proxies (black list?)  INVITE to unresponsive TCP port  INVITE to co-operating but unresponsive node  Colluding node, too many open sessions

17. 17 Possible Extensions ► Captchas ► Scoring (and its authentication) ► Logging of filtered calls?

18. 18 Bibliography ► RFC3261, RFC2543, RFC4474 ► VOIP Intrusion Detection Through Interacting Protocol State Machines ► VoIP Honeypot Architecture ► Understanding SIP ► VoIP Security and Privacy Threat Taxonomy ► Survey of Security Vulnerabilities in SIP

19. 19 ISP C1 C2 C3 SF Basic Architecture: Deployment P Re INTERNET SIP traffic Ro Non-SIP traffic Ro SIP IN traffic: to SF Filter only IN traffic to SF

20. 20 NATs: Enterprise Scenario C1 ISP A (SRC) Internet ISP B (DST) ISF C2 C3 PAPA RARA PAPA RARA ESF C4 Filter Request, send to ISF@domain NAT

21. 21 NATs: End-Customer Scenario C1 ISP A ISF C2 C3 PAPA RARA NAT HOME Internet ► ISF can only ingress filter for NAT’s MAC ► R has multiple SIP IDs for NAT’s IP ► Filter: C1@ISPA ► C2 can still DoS C1, but this is local problem 128.16.6.8 C1 : 128.16.6.8 C2 : 128.16.6.8 C3 : 128.16.6.8

22. 22 Experiment Results

23. Typical SIP Message Sizes SIP Message TypePayload Size (in bytes) ACK360 INVITE514 RINGING560 OK916 23 Payload size is the message size plus the IP/UDP headers

24. Network Topology 24 ► Computer91 (Dell 2950) ► 8 cores (2 x Intel Xeon X5355@2.66GHz) X5355@2.66GHz ► 8 GB memory ► 3 Intel 82571EB Quad Port cards on PCI-e slots ► All others (Dell 1950) ► 4 cores (2 x Intel Xeon 5150@2.66Ghz) 5150@2.66Ghz ► 2 GB memory ► 2 Intel 82561EB Dual Port cards on PCI-e slots

25. PF_RING Performance 25

26. Click Configuration Files (I) 26 c0 :: Classifier(12/0800, -); out0 :: Queue(200); pdeth13 :: PollDevice(eth13, PROMISC true) -> c0; // IP packets c0[0] -> Strip(14) -> CheckIPHeader() -> Strip(28) -> Unstrip(28) -> out0; // All others c0[1] -> out0; out0 -> tdeth11 :: ToDevice(eth11); Click SIP Forwarder

27. Click Configuration Files (II) 27 methclassifer0 :: SIPMethodClassifier("INVITE", "-"); c0 :: Classifier(12/0800, -); out0 :: Queue(200); pdeth13 :: PollDevice(eth13, PROMISC true) -> c0; // IP packets c0[0] -> Strip(14) -> CheckIPHeader() -> Strip(28) -> methclassifer0; methclassifer0[0] -> Discard; methclassifer0[1] -> Unstrip(28) -> out0; // All others c0[1] -> out0; out0 -> tdeth11 :: ToDevice(eth11); Click SIP method filter

28. 28 Click Configuration Files (III) 28 filter0 :: SIPHashFilter("From" "URI", "To" "URI"); c0 :: Classifier(12/0800, -); out0 :: Queue(200); pdeth13 :: PollDevice(eth13, PROMISC true) -> c0; // IP packets c0[0] -> Strip(14) -> CheckIPHeader() -> Strip(28) -> filter0 -> Unstrip(28) -> out0; // All others c0[1] -> out0; out0 -> tdeth11 :: ToDevice(eth11); Click SIP hash-based headers filter

29. 29 Click Configuration Files (IV) 29 StaticThreadSched( pdeth13 0, tdeth13 0, pdeth11 0, tdeth11 0, pdeth12 1, tdeth12 1, pdeth10 1, tdeth10 1, pdeth9 2, tdeth9 2, pdeth7 2, tdeth7 2, pdeth8 3, tdeth8 3, pdeth6 3, tdeth6 3, pdeth5 4, tdeth5 4, pdeth3 4, tdeth3 4, pdeth4 5, tdeth4 5, pdeth2 5, tdeth2 5); Click Threads

30. Click (old parser) Performance 30

31. Click (new parser) Performance 31

32. Click Hash-based Performance 32

33. Number of Filters Chain Length Number of Hash Buckets 1005001,0005,00010,000 5 5002,5005,00025,00050,000 50 5,00025,00050,000250,000500,000 75 7,50037,50075,000375,000750,000 100 10,00050,000100,000500,0001,000,000 200 20,000100,000200,0001,000,0002,000,000 300 30,000150,000300,0001,500,0003,000,000 400 40,000200,000400,0002,000,0004,000,000 500 50,000250,000500,0002,500,0005,000,000 33 Figures in red denote line-rate configurations