Randomized Failover Intrusion-Tolerant Systems (RFITS)

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

2. Project Introduction • Objective • Demonstrate viability of randomized failover concept for building survivable 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” • large failover space makes it difficult for attacker to acquire knowledge of system state needed to adapt attack • Focus on network borne denial-of-service attacks • Flooding (packet, service request) • Host takedown

3. Project Introduction (Cont’d) • Accomplishment to date • Developed handbook of survivability design patterns • Survivable information transport services • Survivable server groups • Applied selected design patterns to develop VPNshield • Completed prototype implementation of VPNshield • Demo at DARPAtech 2002 • Network 2002 paper • Completed initial prototype of FlowShield • Developed design of DoS-resistant JMS • Participated in Peer Review Validation of VPNshield

4. FlowShield Design Goals • Protect mission-critical information flows from flooding DoS attacks • protection on per packet flow basis • guaranteed share of access link bandwidth for protected packet flows • application transparent • no changes to existing core network infrastructure • Supplement infrastructure based DDoS defenses

5. FlowShield Approach Overview • Packet flows are uniquely identified by their flow labels ( source IP addr., dest. IP address) • For each protected flow, the FlowShield endpoint reserves a fraction of the access link bandwidth • Upon detection of a flooding attack, FlowShield endpoints “transmute” the label of the protected flow • Access link reservation for old flow label is canceled. Reservation installed for new label

6. FlowShield: Appliance Based Implementation • FlowShield appliance at boundary of edge network embeds mechanisms for • detection of flooding attacks • flow label transformation and link re-provisioning

7. FlowShield: Appliance Based Implementation (Cont’d) • FlowShield POP appliance(s) associated with each edge appliance • serves as tunnel concatenation device

8. 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. • Shared secrets between FlowShield appliances 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

9. Applying RFITS Techniques to Protect JMS from Flooding Attacks • The Java Message Service (JMS) specification defines a messaging interface for Java applications. • It supports both queuing and publish/subscribe. • Message-based applications are vulnerable to denial of service attacks at the messaging level. • Attacker can flood message service with spurious messages. • Prevents application from acting on real messages. • Such attacks may not be visible at the network level • “Life-cycle” attacks • Rogue JMS client planted by insider • Access control may not prevent attacks • Programming errors

10. Example JMS Implementation

11. JMS Denial of Service Attack Message flood

12. JMS Channel Partitioning

13. JMS Channel Partitioning • To survive DOS attack by client When client requests topic for “T” through JNDI interface, assign alias topic Tk instead of T itself. • Maintain the Tk  T partition mapping at the service center. • If client launches DOS attack on topic Tk, invalidate topic Tk and refuse new topic requests from client host associated with topic Tk. • Other message service clients continue to function • Clients communicating through other aliases for T • New clients requesting topic for “T” from other hosts • Why does this work? • Each client is segregated into a distinguishable topic, which can be invalidated selectively. • This defense is also effective for message queues.

14. Distributed JMS with Local Topic Aliases Message to T Y manages topic T Message to T2 Delivered from T4

15. Conclusion and Future Plans • Demonstrated application of RFITS survivability design patterns to protect information flows at different levels of granularity • aggregated flows (VPNshield) • individual flows (FlowShield) • pub/sub messaging (DoS-resistant JMS) • Planned work • Prototype implementation of FlowShield appliances • FlowShield customization for CECOM SMS • Refine and extend design of DoS-resistant JMS