1 / 23

Network Infrastructure Security Research at Colorado State University

Network Infrastructure Security Research at Colorado State University. Dan Massey November 19, 2004. Network Infrastructure. Protocols and Components That Enable Communication Routing protocols to deliver data from source to destination. Ex: Internet’s global BGP routing protocol

elyse
Download Presentation

Network Infrastructure Security Research at Colorado State University

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Network Infrastructure Security Research at Colorado State University Dan Massey November 19, 2004

  2. Network Infrastructure • Protocols and Components That Enable Communication • Routing protocols to deliver data from source to destination. • Ex: Internet’s global BGP routing protocol • Naming protocols identify critical resources • Ex: Internet’s DNS naming protocols • Focus of This Talk is Internet BGP and DNS • But observations and research results apply to other systems such as sensor networks, ad hoc wireles, etc. USAFA Front Range Workshop for Information Security

  3. Original Infrastructure Goals • The original designs assumed that: • Hardware is unreliable: servers/routers will fail • Network links are unreliable: connections will fail • Data transport is unreliable: bit errors will occur • The goal was to build protocols that : • Provide functionality despite all of the above • Scale to extremely large size • Tremendously successful in this respect: • BGP routing protocol - 150K+ routes 20K+ systems • DNS naming protocol - 1G of records in 60M zones • But fails to address configuration errors, attacks, etc. USAFA Front Range Workshop for Information Security

  4. BGP Routing Infrastructure • Internet’s Global Routing Protocol • Connects Autonomous Systems (AS) • Path Vector Routing Protocol • Announce the path of AS used to reach destination • Routes adapt to: • Link changes & route polices • Does not adapt to traffic load. • Some Causes For Concern Today • Selection of a single path • Unexpected interactions with data • Lack of any route authentication Prefix P AS 1 AS 2 AS 3 Prefix P Path 2,1 Prefix P Path 3,1 USAFA Front Range Workshop for Information Security

  5. Consequences of Global Trust • BGP Provides No Authentication • Faults and attacks can mis-direct traffic. • One (of many) examples observed in BGP logs. (Incorrectly) decides it is the owner of 192.26.92/24 ISPs announced new path for 20 minutes to 3 hours Internet Owner of 192.26.92/24 BGP monitor USAFA Front Range Workshop for Information Security

  6. Multiple Origin AS (MOAS) Cases • Prefixes originate from Multiple Origin AS (MOAS) • Lower curve likely due to valid operational needs • Spikes are errors that disrupt routing to prefix • Includes loss of routes to top level DNS servers USAFA Front Range Workshop for Information Security

  7. Local or Global Impact? • Traffic to 192.26.92/24 routes to wrong site. • Clearly a problem for that site, but do you care? • Yes, if some essential service hosted there…. False origin of 192.26.92/24 ISPs announced new path for 20 minutes to 3 hours Internet Owner of 192.26.92/24 BGP monitor C gTLD DNS Server Here USAFA Front Range Workshop for Information Security

  8. Interplay Between BGP and DNS www.cisco.com A? Root DNS Server www.cisco.com A 128.92.1.3 End-user Caching DNS Server com?? DNS Server Actually 128.92.1.3 is Colorado State, but how would you determine this? Recall routing delivered this DNS query to the false com server. cisco.com DNS Server USAFA Front Range Workshop for Information Security

  9. Cryptography is like magic fairy dust, we just sprinkle it on our protocols and its makes everything secure - See IEEE Security and Privacy Magazine, Jan 2003 USAFA Front Range Workshop for Information Security

  10. Authentication of DNS Responses • Each DNS zone signs its data using a private key. • Recommend signing done offline in advance • Query for a particular record returns: • The requested resource record set. • A signature (SIG) of the requested resource record set. • Resolver authenticates response using public key. • Public key is pre-configured or learned via a sequence of key records that follow the DNS heirarchy. USAFA Front Range Workshop for Information Security

  11. Secure DNS Query and Response Caching DNS Server www.darpa.mil Authoritative DNS Servers www.darpa.mil = 192.5.18.195 Plus (RSA) signature by darpa.mil End-user Attacker can not forge this answer without the darpa.mil private key. USAFA Front Range Workshop for Information Security

  12. DNS Security Activities • Co-editor of the IETF specification [8]. • Passed IETF Standards Process, waiting for RFC#. • Code available in BIND 9.3.X DNS servers • Encouraging sites to deploy secure DNS • Operator tools and guidelines in progress • Currently Investigating Resilient DNS • Authentication can defend against false route • Responses from the false server are ignored • But does not solve denial of service….. • Security is more than authentication. • Ensure diverse availability of DNS servers and data • SIGCOMM 04 DNS resilience paper USAFA Front Range Workshop for Information Security

  13. Authentication of BGP Updates? • Apply Same Public Key Cryptography to BGP Updates? • Existing proposals for Secure BGP (BBN) and Secure Origin BGP (Cisco) • But additional challenges in BGP/Routing • No clear hierarchy to overlay public key infrastructure (PKI) • No guarantee data follows the authenticated route • Need additional services to segregate and block data traffic • Routing faces other interactions and problems…. USAFA Front Range Workshop for Information Security

  14. There is no magic fairy dust USAFA Front Range Workshop for Information Security

  15. The Internet Slammer Worm Figure by CAIDAWorm Propagation After 30 Minutes USAFA Front Range Workshop for Information Security

  16. Total Attack Routing Changes Brittle BGP Sessions BGP Updates During Nimda Worm USAFA Front Range Workshop for Information Security

  17. Work on Improving Routing Security • Worm Shows Some Complexity of BGP Dynamics • Need to stabilize the peer communication • Proposed a fast bloom filter verification mechanism (FRTR) • Need to identify real source topology events • Proposed Root Cause Tags and LinkRank Analysis Tools • Need to validate routing updates. • Exploiting natural (non-crypt) consistency assertions • Need to better exploit redundant network paths. • DARPA Control Plane (kickoff yesterday) • But we must not forget that ultimate goal of routing is to delivery packets. USAFA Front Range Workshop for Information Security

  18. Open Challenges • How to Build Next Generation Infrastructure (routing/naming) protocols that function in today’s network? • Assume some compromised/malicious nodes • Fact of life in large scale system or critical (DoD) system • Assume malicious traffic (worms) • Protect underlying infrastructure from data impact • Identify and block undesired traffic at infrastructure • Apply Cryptographic Authentication When Possible • But recognize authentication is not equivalent to security • Much Interesting Work To Be Done… • In Internet, DoD networks, new sensor networks, etc. USAFA Front Range Workshop for Information Security

  19. Acknowledgements • Funding Sources - Active • NetPath: November 2004 - November 2005 • DARPA Control Plane Program • Beyond BGP Project: October 2002 - September 2005 • NSF Special Projects in Networking • Funding Sources - Recently Completed • FMESHD Project: Concluded June 2004 • DARPA Fault Tolerant Networks • FNIISC Project: Concluded June 2004 • DARPA Fault Tolerant Networks • With Thanks to Collaborators • DARPA: Col. Tim Gibson • DHS: Dr. Doug Maughan • UCLA: Lixia Zhang, Beichuan Zhang, Lan Wang, Dan Pei, Mohit Lad USAFA Front Range Workshop for Information Security

  20. Questions?

  21. FRTR: Improving Router Communication • BGP Updates Are Not (Topology) Event Driven • Session resets trigger high volume surges • Govindan shows cascade failures can result. • Lifetime of Invalid Routes is Unbounded • Never recover (until reset) if update is somehow lost. • Despite TCP, we found cases of “lost” withdrawals. • Attacker can poison a route with one update. • Soft-state (periodic re-announce) is too costly… • FRTR Uses Periodic Bloom Filter Digests • Digests quickly confirm state after session reset. • Periodic digests bound lifetime of faults (w/ high prob). • Co-Author Keyur Patel (Cisco) is exploring Cisco development. USAFA Front Range Workshop for Information Security

  22. FRTR Performance • For each route at receiver, check against the digest. • Bloom filter results in no false negatives. • Compare total digests for missing route detection. • False positive possible with known rate. • Add salts to reduce the chance of repeated false positives. • Overhead is a function of digest size and frequency. • Work with Cisco suggests a 1.3% overhead increase. • Complete Details to in [3] (DSN 2004) USAFA Front Range Workshop for Information Security

  23. Link Rank BGP Dynamics USAFA Front Range Workshop for Information Security

More Related