Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Network Infrastructure Security Research at Colorado State University Dan Massey November 19, 2004."— Presentation transcript:

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

2 11/19/04 USAFA Front Range Workshop for Information Security 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.

3 11/19/04 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.

4 11/19/04 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 AS 1 AS 2AS 3 Prefix P Path 2,1 Prefix P Path 3,1

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

6 11/19/04 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

7 11/19/04 USAFA Front Range Workshop for Information Security 7 Local or Global Impact? Internet BGP monitor Owner of 192.26.92/24 False origin of 192.26.92/24 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…. ISPs announced new path for 20 minutes to 3 hours C gTLD DNS Server Here

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

9 11/19/04 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

10 11/19/04 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.

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

12 11/19/04 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

13 11/19/04 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….

14 11/19/04 USAFA Front Range Workshop for Information Security 14 There is no magic fairy dust

15 11/19/04 USAFA Front Range Workshop for Information Security 15 The Internet Slammer Worm Figure by CAIDA Worm Propagation After 30 Minutes

16 11/19/04 USAFA Front Range Workshop for Information Security 16 BGP Updates During Nimda Worm Brittle BGP Sessions Routing Changes Total Attack

17 11/19/04 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.

18 11/19/04 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.

19 11/19/04 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

20 Questions?

21 11/19/04 USAFA Front Range Workshop for Information Security 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.

22 11/19/04 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)

23 11/19/04 USAFA Front Range Workshop for Information Security 23 Link Rank BGP Dynamics


Download ppt "Network Infrastructure Security Research at Colorado State University Dan Massey November 19, 2004."

Similar presentations


Ads by Google