Randomized Failover Intrusion-Tolerant Systems (RFITS)

1. Randomized Failover Intrusion-Tolerant Systems (RFITS) Ranga Ramanujan, Maher Kaddoura, John Wu, Clint Sanders, Doug Harper, David Baca Architecture Technology Corporation (ATC) ATC-NY (formerly Odyssey Research Associates) DARPA OASIS PI Meeting March 13, 2002

2. Project Introduction • Objective • Demonstrate how the randomized failover concept can be applied to build organic DoS-resistance mechanisms for mission-critical network applications • What is randomized failover? • Approach for system survivability based on the notion that attackers can be thwarted by making the failover process invoked by the system upon detection of an attack appear unpredictable or “random” • make it difficult for attacker to acquire knowledge of system state needed to adapt attack • designed to complement non-organic mechanisms in a layered DDoS defense system

3. Project Introduction (Cont’d) • Accomplishment to date • Developed handbook of survivability design patterns • Applied selected design patterns to develop VPNshield, an organic defense system for protecting mission-critical VPN services from flooding DoS attacks • Completed prototype implementation of VPNshield

4. VPNshield Design Goals • Organic approach for protecting mission-critical VPNs from flooding DoS attacks • IPSEC based site-to-site and remote access VPNs • uninterrupted operation of VPN service • guaranteed share of access link bandwidth for VPNs • reliable attack detection with fully automated failover response • actionable information for other DoS protection tools • no changes to core network infrastructure

5. Why VPNshield? • DoS flooding attacks over the Internet are real. Backscatter analysis by Savage et al reported • Over 12,800 incidents over a 3 week period • More than 5000 different victims in over 2000 DNS domains • pulsing attacks to continuos attacks (600,000 pps) • Existing infrastructure based techniques for DDoS protection may be insufficient for VPNs • Signature and anomaly based attack detection within infrastructure is difficult for encrypted VPN traffic • Hard to distinguish between spoofed and real traffic • Person-in-the-loop may be needed for pushback response, incurring delays • VPNshield’s organic approach represents another layer of defense to supplement infrastructure based DDoS defense techniques

6. Background and Definitions • CE Router • Customer premise IP router with embedded VPNshield mechanisms • End point of IPSEC site-to-site or remote-access tunnel • Implements attack detection mechanism and initiates failover • PE Router • ISP premise IP router at head-end of access link • Provisions and manages bandwidth over access link for CE VPNs

7. Assumptions About Threat Environment • Flooding attacks are launched from the edge of the shared, public network. Attacker does not have access to core of the shared network. • Attack traffic does not originate from any of the customer equipment within the protected network. All attacks are outsider attacks. • Shared secrets between CE routers are adequately protected against compromise • Volume of traffic may be sufficient to inundate access link but not sufficient to disrupt operation of service provider network

8. VPNshield Approach Overview • CE routers provision redundant public IP addresses for each VPN tunnel end-point • current address • standby addresses • Each VPN packet flow is uniquely identified by the ordered pair (tunnel source IP addr., tunnel dest. IP address) • For each arriving VPN flow, a CE router reserves a fraction of the access link bandwidth using a truncated RSVP reservation • Virtual firewall at PE router guards provisioned access link resources against all spurious attack traffic except spoofed packets

9. VPNshield Approach (Cont’d) • CE router detects spoofed packet flood attack by monitoring packet authentication failure rate • Failover mechanism invoked by CE router upon reconfigures the label of the victim flow • new source and/or destination address of victim VPN tunnel selected from list of standby addresses • Concurrently, victim CE router cancels RSVP reservation for old flow and installs reservation for new flow • Attack traffic carrying old flow label is filtered out upstream of the victim access link

10. VPNshield Approach (Cont’d) • For an attacker with no knowledge of the set of standby addresses of the two end points of the VPN, the failover process appears unpredictable or “random”. • If S1 and S2 represent the sets of all possible values for the source and destination address components of a flow label (a,b), then from the perspective of an attacker the new label assigned to a victim flow by the randomized VPN failover process can take any value from among | S1|*| S2| possibilities • The VPNshield approach relies on designing sufficient address space diversity to make it difficult for an attacker to determine the new configuration of the VPN and adapt the attack • Two alternative implementation techniques for the VPN failover process • tunnel reconfiguration with unicast addressing • tunnel reconfiguration with multicast addressing

11. Tunnel Reconfiguration with Unicast Addressing • Employs unicast IP addresses for both endpoints of a VPN tunnel • Address space diversity limited by the range of addresses allocated to the edge networks • VPN tunnel splitting overcomes this problem • VPN tunnel from A to B is split into two tunnels through a tunnel concatenation device (TCD) • Address space diversity with tunnel splitting is (size of IP unicast IP address space)*(size of destination address space) or approximately 3.7*109*(size of destination address space)

12. VPN Tunnel Splitting • Additional mechanisms for robust split tunnel operation include • packet authentication at TCD • heartbeat protocol for detecting and recovering from TCD failures

13. Tunnel Reconfiguration with Multicast Addressing • Destination address of a VPN tunnel is an IP multicast address • CE router maintains a list of alternate multicast and unicast addresses for each terminating and originating VPN tunnel, respectively • Employs source specific multicast, an extension of the traditional IP multicast service • SSM supports multicast channels uniquely identified by the destination SSM address, M, and the unicast source address, S • Failover process implemented by a victim CE router switches channels upon detection of a flooding attack • source send packets on new channel • RSVP reservation reconfigured for new flow • Attack traffic directed at old channel is pruned by the multicast routing mechanism at router close to the source

14. Comparison of Tunnel Reconfiguration Techniques

15. VPNshield Demonstration • Implements tunnel reconfiguration with unicast addressing • site to site VPN (RAS VPN not supported currently) • Demonstration products include • CE router with VPNshield (Windows NT/2000) • PE router with RSVP support (Windows NT/2000) • Attack tool (Windows 98/NT/2000)

16. VPNshield Demonstration (Cont’d) RealVideo stream profile under attack traffic (without VPNshield) RealVideo stream profile under attack traffic (with VPNshield)

17. Conclusions and Planned Work • Address space diversity provided by VPNshield’s randomized failover process seems sufficient to thwart attackers long enough to enable complementary DDoS defenses to isolate and neutralize attackers • Alternative UDP tunneling implementation can increase address space diversity by 232 • How can the effectiveness of the approach be measured and validated? • Planned work • Internal red team exercise • developed testing tools to aid process • VPNshield implementation for mobile clients • Defenses against dial port flooding attacks