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

2 May 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

2 May 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.

2 May Example Infrastructure Problems l BGP Routing Fault Example: n ISP mistakenly announced routes to 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”.

2 May A More Interesting Example Internet c.gtld-servers.net rrc00 monito r originates route to /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

2 May 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 protecting BGP routes to DNS servers Bell Labs Caching Server Root server Spoofed Root server Internet Routing

2 May 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

2 May l Virtually every application uses the Domain Name System (DNS). l DNS database maps: n Name to IP address = 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

2 May DNS Query and Response Caching DNS Server End-user A? A Root DNS Server Actually = But how would you determine this? mil DNS Server darpa.mil DNS Server

2 May 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.

2 May A Simple DNS Attack Caching DNS Server Sanjoy’s Laptop A? A 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. A First response wins. Second response is silently dropped on the floor.

2 May A More Complex Attack ns.attacker.com Bell Labs Caching Server Remote attacker Query Response A attacker.com NS ns.attacker.com attacker.com NS ns.attacker.com A A Any Bell Labs Laptop Query =

2 May 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.

2 May 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.

2 May Secure DNS Query and Response Caching DNS Server End-user = 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

2 May Example of Signed Record zen.nge.isi.edu IN A zen.nge.isi.edu IN SIG A ( 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

2 May Example Public Key nge.isi.edu IN KEY ( 2gHZzvcB01VSnjF9K+0eet1sUQrGprMZC1Kn FNLSeJMMjN0Aw4Ewj5+Il8ejvqO0lX+njNOo EzlhXAV+mp5dT0WjJB+78Nv51UEHW0bQnt05 nge.isi.edu IN SIG KEY ( 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

2 May There is no magic fairy dust

2 May 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?

2 May 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

2 May 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

2 May Revised DNS Key Management mil DNS Server darpa.mil DNS Server darpa.mil NS records A record 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

2 May 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

2 May 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.

2 May 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.

2 May 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.

2 May 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 ….

2 May 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!)

2 May 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….

2 May 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?

2 May 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.

2 May 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.

2 May 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

2 May 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.

2 May Non-cryptographic BGP Security router bgp 59 neighbor remote-as 52 neighbor send-community neighbor route-map setcommunity out route-map setcommunity match ip address /8 set community 59:MOAS 58:MOAS additive Example configuration: AS58 18/8, PATH, MOAS{4,58,59} AS /8 18/8, PATH, MOAS{58,59} 18/8, PATH, MOAS{52, 58} AS52

2 May (b) Two Origin AS’s(a) One Origin AS BGP false origin detection Simulation Results

2 May 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.