Securing Information Transmission by Redundancy - PowerPoint PPT Presentation

salena
securing information transmission by redundancy l.
Skip this Video
Loading SlideShow in 5 Seconds..
Securing Information Transmission by Redundancy PowerPoint Presentation
Download Presentation
Securing Information Transmission by Redundancy

play fullscreen
1 / 13
Download Presentation
Securing Information Transmission by Redundancy
233 Views
Download Presentation

Securing Information Transmission by Redundancy

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Securing Information Transmission by Redundancy Jun Li Peter Reiher Gerald Popek Computer Science Department UCLA NISS Conference October 21, 1999

  2. Outline • Interruption threats are hard to counter • Redundant transmission makes interruptions harder • But redundant transmission is not as easy as using redundancy in other areas • Sample uses • Conclusion

  3. Interruption Threats Destination Source An interruption attack occurs Result? No data flows to the destination

  4. Problem • Many kinds of interruption threats • Corrupted routers drop packets • Transmitting over packets on shared media • Congesting links or routers • Conventional approaches won’t help • Encrypted/signed message can still be interrupted • Acknowledgement won’t help either • The acknowledgement itself is subject to interruption • Retransmission means possibly failing again • So?

  5. receiver Using Redundancy To Counter Interruptions • Don’t use a single path • Any point on the single path is a point of failure • Use redundancy to secure transmission • Only parallel redundancy considered here • A node is expected to receive multiple copies of one message • Successful if at least one copy is authentically received • Redundancy has been widely used in other areas • High availability storage • Replicated execution • And many others

  6. How does redundant deliver help? What if a router is corrupted? A Simple Example Source Normal delivery uses a default path The redundant copy gets through despite a bad router Destination

  7. sender receiver But . . . • Redundant transmission is tough • Discovering disjoint paths is difficult • Routing is transparent to applications • Using disjoint paths is difficult • They may not exist at all • Can try to be as disjoint as possible nevertheless • An attacker has to find a choke point or break multiple points • Scale can also cause big problems • And what about costs of sending multiple copies?

  8. Sample Uses of Redundancy • Revere • Secure delivery of security updates • General purpose redundant packet delivery service • Redundancy for every network user?

  9. Revere • Goal: disseminate security updates to large number of machines • Assume a trusted dissemination center • Security updates • Small size but critical information • Examples: • New virus signature • New intrusion detection signature • CRL (certificate revocation lists) • Offending characteristics for a firewall to monitor

  10. Revere Structure • Acks/Nacks inappropriate • Scaling, lack of complete trust, etc. • Use redundancy to send multiple copies to each node • Each node can also forward security updates to others • A node can contact multiple repository nodes for missed updates

  11. General Redundant Packet Delivery Services • How could we add a redundant packet delivery service to the Internet? • What would be the best method of achieving redundancy? • Know a lot about the network? • Or rely on randomness and obscurity? • What are the costs of doing so? • How could it be easily deployable? • Proxy-based solutions?

  12. Conclusion • Conventional security approaches and transmission primitives don’t adequately counter interruption threats • Redundancy is a promising tool • But effective use of redundancy is challenging • Are there other problems that redundancy can solve? • Does redundancy itself lead to new security threats?

  13. Questions • Contact information • Peter Reiher: reiher@cs.ucla.edu • Jun Li: lijun@cs.ucla.edu • Gerald Popek: popek@cs.ucla.edu