1. Designing a Secure and Resilient Internet Infrastructure Dan Massey USC/ISI

2. 2 May 032masseyd@isi.edu Overview l Internet Infrastructure n Overview and Vulnerabilities l Securing the Domain Name System n IETF Standard for Authentication of DNS Responses n Critical Failures and Lessons Learned l Open Challenges for Infrastructure Security

3. 2 May 033masseyd@isi.edu Internet Infrastructure l Internet relies on fundamental infrastructures n BGP Internet Routing Protocol n DNS Internet Naming Service l Failure at these levels often can’t be overcome. n Provide basic packet delivery functions. l Protocol Designs Show Signs of Age n Growing complexity of large-scale systems. n Demand for new features and services. n Primarily designed for only fail-stop faults. n Little or no protection against malicious attacks.

4. 2 May 034masseyd@isi.edu Example Infrastructure Problems l BGP Routing Fault Example: n ISP mistakenly announced routes to 3000+ prefixes (destinations) it did not own. n Other ISPs adopt these routes and blackholed traffic to those sites. l DNS Root Server Attack Example: n Recent DDoS attack disabled majority of the 13 DNS root servers. n Bringing down all 13 root servers is frequently mentioned as a worst case scenario that would “cripple the Internet”.

5. 2 May 035masseyd@isi.edu A More Interesting Example Internet c.gtld-servers.net rrc00 monito r 192.26.92.30 originates route to 192.26.92/24 l Invalid BGP routes exist in everyone’s table. n These can include routes to root/gTLD servers n One example observed on 4/16/01: ISPs announce new path 3 lasted 20 minutes 1 lasted 3 hours

6. 2 May 036masseyd@isi.edu The Potential Catastrophic Attack l BGP routing can direct packets to false server. l Detected false BGP routes to root/gTLD severs at major global ISPs. n Routes lasted up to hours, but were errors and faulty site did not reply. l Any response from false server would be believed. n NANOG 25/ICDCS 2003 - protecting BGP routes to DNS servers Bell Labs Caching Server Root server Spoofed Root server Internet Routing

7. 2 May 037masseyd@isi.edu Securing the Internet Infrastructure 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

8. 2 May 038masseyd@isi.edu l Virtually every application uses the Domain Name System (DNS). l DNS database maps: n Name to IP address www.darpa.mil = 128.9.176.20 n And many other mappings (mail servers, IPv6, reverse…) l Data organized as tree structure. n Each zone is authoritative for its local data. Root edumilcom darpaisiciscousmc nge quantico The Domain Name System

9. 2 May 039masseyd@isi.edu DNS Query and Response Caching DNS Server End-user www.darpa.mil A? www.darpa.mil A 128.9.128.127 Root DNS Server Actually www.darpa.mil = 192.5.18.195. But how would you determine this?www.darpa.mil mil DNS Server darpa.mil DNS Server

10. 2 May 0310masseyd@isi.edu DNS Vulnerabilities l Original DNS design focused on data availability n DNS zone data is replicated at multiple servers. n A DNS zone works as long as one server is available. –DDoS attacks against the root must take out 13 root servers. l But the DNS design included no authentication. n Any DNS response is generally believed. n No attempt to distinguish valid data from invalid. –Just one false root server could disrupt the entire DNS.

11. 2 May 0311masseyd@isi.edu A Simple DNS Attack Caching DNS Server Sanjoy’s Laptop www.darpa.mil A? www.darpa.mil A 128.9.128.127 Root DNS Server mil DNS Server darpa.mil DNS Server Dan’s Laptop Easy to observe UDP DNS query sent to well known server on well known port. www.darpa.mil A 192.5.18.19 First response wins. Second response is silently dropped on the floor.

12. 2 May 0312masseyd@isi.edu A More Complex Attack ns.attacker.com Bell Labs Caching Server Remote attacker Query www.attacker.com Response www.attacker.com A 128.9.128.127 attacker.com NS ns.attacker.com attacker.com NS www.google.com ns.attacker.com A 128.9.128.2 www.google.com A 128.9.128.127 Any Bell Labs Laptop Query www.google.com www.google.com = 128.9.128.127

13. 2 May 0313masseyd@isi.edu The Problem in a Nutshell l Resolver can not distinguish between valid and invalid data in a response. l Idea is to add source authentication n Verify the data received in a response is equal to the data entered by the zone administrator. n Must work across caches and views. n Must maintain a working DNS for old clients.

14. 2 May 0314masseyd@isi.edu Authentication DNS Responses l Each DNS zone signs its data using a private key. n Recommend signing done offline in advance l Query for a particular record returns: n The requested resource record set. n A signature (SIG) of the requested resource record set. l Resolver authenticates response using public key. n Public key is pre-configured or learned via a sequence of key records in the DNS heirarchy.

15. 2 May 0315masseyd@isi.edu 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 Challenge: add signatures to the protocol manage DNS public keys

16. 2 May 0316masseyd@isi.edu Example of Signed Record zen.nge.isi.edu. 82310 IN A 65.114.169.197 zen.nge.isi.edu. 86400 IN SIG A 1 5 86400 20030226023910 ( 20030127023910 468 nge.isi.edu. 2gHZzvcB01VSnjF9K+0eet1sUQrGprMZC1Kn FNLSeJMMjN0Aw4Ewj5+Il8ejvqO0lX+njNOo EzlhXAV+mp5dT0WjJB+78Nv51UEHW0bQnt05 PQ86nXaTTXXQyYE3PSrmASfwXyVlXh430ty3 oWZUZdBZUgvqRGT97xLtagdrCq0= ) name TTL class SIG type_covered algorithm labels_in_name original_TTL expiration and inception dates key tag key name signature

17. 2 May 0317masseyd@isi.edu Example Public Key nge.isi.edu. 82310 IN KEY 256 3 1 ( 2gHZzvcB01VSnjF9K+0eet1sUQrGprMZC1Kn FNLSeJMMjN0Aw4Ewj5+Il8ejvqO0lX+njNOo EzlhXAV+mp5dT0WjJB+78Nv51UEHW0bQnt05 nge.isi.edu. 86400 IN SIG KEY 1 3 86400 20030226023910 ( 20030127023910 569 isi.edu. 2gHZzvcB01VSnjF9K+0eet1sUQrGprMZC1Kn FNLSeJMMjN0Aw4Ewj5+Il8ejvqO0lX+njNOo EzlhXAV+mp5dT0WjJB+78Nv51UEHW0bQnt05 PQ86nXaTTXXQyYE3PSrmASfwXyVlXh430ty3 oWZUZdBZUgvqRGT97xLtagdrCq0= ) name TTL class KEY FLAGS PROTOCOL Algorithm public key Note nge.isi.edu KEY is signed by isi.edu private key

18. 2 May 0318masseyd@isi.edu There is no magic fairy dust

19. 2 May 0319masseyd@isi.edu So Why Aren’t We There Yet l Scope of DNS security too broad n Attempt to solve DNS security and build generic global PKI at same time. l RFC 2535 design was fatally flawed. n Key management did not scale and did not work in realistic operations. l Progress on Improving DNSSEC. n RFC 3449 now limits scope to secure DNS. n Revised DNS key management system implemented and verified at workshops. n Authenticated denial of existence? or security?

20. 2 May 0320masseyd@isi.edu Bush, Griffin, Meyer: draft-ymbk-arch-guidelines- 03.txt The implication for carrier IP networks then, is that to be successful we must drive our architectures and designs toward the simplest possible solutions. complexity is the primary mechanism which impedes efficient scaling, and as a result is the primary driver of increases in both capital expenditures (CAPEX) and operational expenditures (OPEX). Mike O’Dell: Lesson: Simple Operations

21. 2 May 0321masseyd@isi.edu RFC 2535 Key Change Process l Signatures from parent zone sit in child zone. n Requires some sync between parent/child l Figure shows process of a key change at edu. l Actual exchange is much more complex. n “com” change assumes rough sync shown here at 22 million different zones ucdavis.eduedu Select KEY set C 1 Sign KEY set C 1 with P 1 KEY set P 1 KEY set C 1 and SIG(P 1 ) entered in child zone Select KEY set P 2 and sign KEY set C 1 Replace P 1 with P 2 Add SIG(P 2 ) to child zone Remove SIG(P 1 ) to child zone

22. 2 May 0322masseyd@isi.edu Revised DNS Key Management mil DNS Server darpa.mil DNS Server darpa.mil NS records www.darpa.mil A record www.darpa.mil SIG(A) by key 2 darpa.mil KEY (pub key 1) darpa.mil KEY (pub key 2) darpa.mil SIG(A) by key 1 darpa.mil DS record (hash of pubkey 1) darpa.mil SIG(DS) by mil private key Can Change mil key without notifying darpa.mil Can Change key 2 without notifying.mil

23. 2 May 0323masseyd@isi.edu DNS Key Roll-Over mil DNS Server darpa.mil DNS Server darpa.mil KEY (pub key 1) darpa.mil KEY (pub key 2) darpa.mil SIG(A) by key 1 darpa.mil DS record (hash of pubkey 1) darpa.mil SIG(DS) by mil private key darpa.mil KEY (pub key 3) darpa.mil SIG(A) by key 3 darpa.mil DS record (hash of pubkey 3) darpa.mil SIG(DS) by mil private key Objective: Replace KEY 1 with new KEY 3

24. 2 May 0324masseyd@isi.edu Minimal Requirements l Parent must indicate how to reach the child. n NS records at parent MUST identify at least one valid name server for child. l Parent must identify a trusted key at child. n DS record at parent MUST match a valid KEY stored at the child.

25. 2 May 0325masseyd@isi.edu Lesson: Protocol Complications l Building on an existing system n Objective is to strengthen the system. n But additions also add stress to weak points. l Some example cases: n Denial of service added by the DS record. n NS records stored at the parent. n Over use of the KEY record.

26. 2 May 0326masseyd@isi.edu Authenticated Denial of Existence l What if the requested record doesn’t exist? n Query for foo.ucla.edu returns “No such name” n How do you authenticate this? l Operations impose challenges. n Can’t predict user would ask for “foo.ucla.edu” n Can’t sign reply on the fly –Query may go to any of serveral servers –You don’t trust all servers with the private key. –Ex: nge.isi.edu master server is at ISI, but secondaries are at UCL (London) and USC.

27. 2 May 0327masseyd@isi.edu NXT Records Caching DNS Server End-user Foo.lucent.com. ? foo.lucent.com. does not exist Some sort of signature to needed…. Authoritative DNS Servers Challenge: Prove name does not exist given that you can’t predict what user might ask you don’t trust authoritative server with private key Solution: sign “next name after a.lucent.com. is g.lucent.com.” More precisely: a.lucent.com NXT g.lucent.com. a.lucent.com SIG NXT ….

28. 2 May 0328masseyd@isi.edu The Opt-In Proposal l Change the semantics of the NXT record. n Current: next name after “a” is “c” n Proposed: next signed name after “a” is “c” l Provides Gradual Roll-Out Inside a Zone n Current: Each name in com needs an NXT and SIG n Proposed: Each signed name in com needs an NXT and SIG l IETF debate concluding…. (hopefully!)

29. 2 May 0329masseyd@isi.edu Status Of DNSSEC l Opt-In/authenticated denial remains issue…. n “com” to deploy within 6 months if yes on Opt-In n Several TLDs ready to deploy. n Working with DARPA/USMC.mil on deployment l Only minor issues remain in spec n IETF DNSEXT working group drafts: –Intro to DNSSEC, DNSSEC Records, DNSSEC Protocol n Comments welcome l Opens the door for new challenges….

30. 2 May 0330masseyd@isi.edu New DNSSEC Decisions l DNSSEC works well in a logical case n What really happens when DNSSEC fails? n Bridging incremental deployment? l Test sites quickly abandoned strict model n Sites configured servers to accept unsigned data even when signed expected. n Sites quickly configured servers to ignore some authentication failures. (expired signatures) l General rule: DNS prefers some answer (even if it fails crypto) to no answer. n What does this mean for the security model?

31. 2 May 0331masseyd@isi.edu A More Realistic View of DNSSEC l Adding security is a non-trivial problem. n Over 10 years of DNSSEC work, no deployment l DNSSEC is not the complete answer. n No defense against denial of service. n More incremental deployment work needed. l DNSSEC enables many new features. n Management of root zones. n New tool (one of many) for achieving truly robust DNS infrastructure.

32. 2 May 0332masseyd@isi.edu Securing BGP l Secure BGP (S-BGP) proposes to add public key cryptography to BGP. n Replace DNS with BGP. Repeat previous slides. l Secure DNS and BGP are essential. l But even when successful, secure BGP/DNS are only part of the solution. n New complexity due to authentication. n Failures in the authentication. n New denial of serivice issues. n Insider attacks.

33. 2 May 0333masseyd@isi.edu General Infrastructure Security l Revisit protocol design given challenges of: n New services (ex: dynamic DNS) n New tools (ex: DNSSEC) n New requirements (DNS as the PKI??) n More scale & complexity (more in routing/BGP) l Multi-fence approach to protocol design n Incorporate cryptography as part of the solution. n Can also achieve resilience throught protocol design without cryptography

34. 2 May 0334masseyd@isi.edu Two Examples of New Fences l Identify inherent consistency requirements: n BGP routes include a path to the destination and paths must be self-consistent. n INFOCOM 02: reject inconsistent paths to avoid false routes. l Add consistency when possible. n BGP allows multiple origins, making it difficult to distinguish valid origins from false origins. n Our fix: list all valid origins in the route update. n DSN 02: attacker can forge the list, but can’t block valid lists in an Internet topology.

35. 2 May 0335masseyd@isi.edu Non-cryptographic BGP Security router bgp 59 neighbor 1.2.3.4 remote-as 52 neighbor 1.2.3.4 send-community neighbor 1.2.3.4 route-map setcommunity out route-map setcommunity match ip address 18.0.0.0/8 set community 59:MOAS 58:MOAS additive Example configuration: AS58 18/8, PATH, MOAS{4,58,59} AS59 18.0.0.0/8 18/8, PATH, MOAS{58,59} 18/8, PATH, MOAS{52, 58} AS52

36. 2 May 0336masseyd@isi.edu (b) Two Origin AS’s(a) One Origin AS BGP false origin detection Simulation Results

37. 2 May 0337masseyd@isi.edu What To Take Away l A new look at the Internet infrastructure n Real practical need to have solutions now. l Adding Cryptography n Some details of DNSSEC and a view of why it is not a trivial problem. l Need for more than just cryptography n Motivation to look at research challenges in designing secure and resilient protocols.