1. Security and Resilience for the Internet Infrastructure Dan Massey USC/ISI

2. 4 June 032masseyd@isi.edu Acknowledgements l Research Funding Sources n NSF Beyond BGP Project n DARPA FNIISC Project n DARPA FMESHD Project l Current Research Team Members n Lixia Zhang, Lan Wang, Dan Pei, Mohit Lad (UCLA) n Felix Wu (UC Davis) & Xiaoliang Zhao (USC/ISI) l New Collaborations n Andreas Terzis (John Hopkins) & Songwu Lu (UCLA)

3. 4 June 033masseyd@isi.edu Overview l The Current Internet Infrastructure n System Overview and Current Threat Model l New Challenges to the Infrastructure. n Dramatic change in scale and behavior. l Current Approach to Enhancements n Called security, but really authentication l The Multiple-Fence Approach

4. 4 June 034masseyd@isi.edu Internet Infrastructure Definition l Provides Fundamental Communication Services. n Necessary (not sufficient) for applications to work. l Internet Infrastructure Protocols Include: n DNS Internet Naming Protocol n BGP Inter-Domain Internet Routing Protocol l For Generic Application X n Use DNS to translate name into IP address n BGP provides reachability to IP address.

5. 4 June 035masseyd@isi.edu The Current Fault Model l Assume any number of fail-stop faults occur. n Any link, router, or server can stop operating. l BGP Routing Works Despite Faults n Rich topology provides multiple potential paths. –Increasing drive toward multi-homing n Adapt to any combination of link/router failure. –With on-going work on improving convergence. l DNS Naming Works Despite Faults n DNS data replicated at multiple servers. n Automatically detect and avoid failed servers.

6. 4 June 036masseyd@isi.edu Coping With Unexpected Faults l Protocols expect only fail-stop faults. l Examples of other faults are well known n Original ARPANET routing malfunction –East coast router reports 0 distance route to UCLA n Revised ARPANET routing complex behavior –Unexpected sequence number combination. l Rely on ad-hoc manual solutions to recover. n Today’s Internet infrastructure works due to –Innate ability to handle fail-stop faults. –Clever operators to handle everything else.

7. 4 June 037masseyd@isi.edu Infrastructure Challenges “For every type of animal there is a most convenient size, and a large change in size inevitably carries with it a change of form.”

8. 4 June 038masseyd@isi.edu The Internet Change in Size l Wider range of heterogeneity l Larger traffic volume l Bigger routing tables l Higher failure frequency l But most importantly : n ever increasing new threats due to growing large n ever increasing complexity due to growing large the Internet continues to grow both in size and in importance

9. 4 June 039masseyd@isi.edu The Fail-Stop View of Disaster l Well known DNS “root server problem” n DNS is a tree structure and queries start at root. n DNS root data stored 13 root name servers. –Tells you how to reach com, net, org, edu, uk, etc. –Identical data at each server allows any server to fail n Loss of all 13 root servers would cripple DNS l Counter measures to the root server problem. n Servers on high bandwidth links. n Strong network and server administration. n Close monitoring to detect attacks. –Lost majority to DDoS, but have never lost all servers.

10. 4 June 0310masseyd@isi.edu Actual Potential for Disaster Internet c.gtld-servers.net BGP monitor 192.26.92.30 originates route to 192.26.92/24 l BGP Provides No Authentication n Faults and attacks can mis-direct traffic. n One (of many) examples observed from BGP logs. ISPs announced new path for 20 minutes to 3 hours

11. 4 June 0311masseyd@isi.edu A Different View of Disaster l Inter-component Complexity Problems n Provided strong protection for real root/gTLD servers. n But overlooked routes leading to these servers. l Limitations of the Fail-Stop Model n Assume BGP router announces legitimate routes. n Assumed DNS server replies with valid data. l Simply Scaling Up the Infrastructure Doesn’t Work n Proposal to increase number of root servers –Use anycast to overcome some protocol restrictions. n But change in size requires change in form. –Must maintain data integrity between more root servers.

12. 4 June 0312masseyd@isi.edu Size Change  Design Change l The Internet's large change in size calls for a fundamental change in network protocol design considerations. n NANOG 28: One operator detected over 5000 compromised routers between Jan 1 - May 31 n NANOG 28: One ISP detected compromise of its entire backbone. l Realistic Threat Model Must Assume n Not all the components will play by the rules. n Things can go wrong in unexpected ways.

13. 4 June 0313masseyd@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

14. 4 June 0314masseyd@isi.edu New Infrastructure Enhancements l Problem: BGP and DNS lack authentication. n Easy to insert false BGP routes. n Easy to reply with false DNS data l Add Public Key Authentication to BGP. n Verify origin is authortized to announce prefix. n Verify each link in the AS path. n Requires some PKI structure. l Add Public Key Authentication to DNS n DNSSEC further along than BGP approaches n DNS provides lessons for BGP authentication.

15. 4 June 0315masseyd@isi.edu Authentication of 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.

16. 4 June 0316masseyd@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

17. 4 June 0317masseyd@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

18. 4 June 0318masseyd@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

19. 4 June 0319masseyd@isi.edu There is no magic fairy dust

20. 4 June 0320masseyd@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.

21. 4 June 0321masseyd@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 Use key 2 only to limit interactions with.mil Note you can change key 2 Without notifying mil

22. 4 June 0322masseyd@isi.edu DNS Key Roll-Over mil DNS Server darpa.mil DNS Server darpa.mil KEY (pub key 1) 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

23. 4 June 0323masseyd@isi.edu Deployment Experience l DNSSEC works well in a logical case n But what really happens when DNSSEC fails? n How do we bridging incremental deployment? l Security Model Evolved in Practice n Started with a strict model to only accept signed responses (or accept a proof the zone was not signed). n But sites configured servers to ignore some authentication failures (expired signatures) and accept unsigned data even when signed expected. l Authentication in the Infrastructure is Different n DNS prefers some questionable answer to no answer. n Same rule will applies to BGP.

24. 4 June 0324masseyd@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.

25. 4 June 0325masseyd@isi.edu The Role of Authentication l Secure DNS/BGP add authentication. n Authentication is not equivalent to security. n And adds new denial of service attacks. l Very Effective in Some Scenarios n Can prefer authenticated data over other data. –Forces attacker to block authenticated data. n But attacker can block authenticated data. –Misconfigurations, older implementations also block. l Authentication primarily enables new services. n Ex: can increase number of DNS root servers. n Ex: can better trace the source of a fault/attack.

26. 4 June 0326masseyd@isi.edu A Truly Secure &Resilient Infrastructure “If a problem has no solution, it may not be a problem, but a fact, not to be solved, but to be coped with over time” — Shimon Peres (“Peres’s Law”)

27. 4 June 0327masseyd@isi.edu Protocol Design for Simple Functionality l Contain the minimal set of bits necessary for data delivery l Explicitly enumerates all possible physical failures n Node failure: fail stop n Link failure: disconnect n Data delivery failure: bit error, our of order, loss, duplicates l Implicitly assumes that n Every component follows the rules n No faults other than physical failures listed above.

28. 4 June 0328masseyd@isi.edu Increased Fault Detection in Practice As reactions to the hostile reality l DHCP user authentication l DoS block boxes n Packet washing machine - ex: Riverhead Networks l ISP traffic filtering n Strongly encourage filtering at the edges. l TTL checking n Filtering out attack traffic n Filtering out bogus BGP messages It is time we start a proactive, systematic approach to Internet resiliency

29. 4 June 0329masseyd@isi.edu Improving the Fault Response l New enhancements address specific faults l Example: overload attack at router CPU n Frequent (daily) problem for AOL routers. n Solution: check TTL and only allow control traffic from one hop away. l Example: false route announcements n Common due to operational errors n Solution: apply cryptography and PKI to check the origin AS is authorized to announce the prefix. l Many other enhancements driven by known faults n Ranging from performance to convergence to security

30. 4 June 0330masseyd@isi.edu Fault-Driven Limitations l The potential space of faults/attacks is vast. n Not possible to list and engineer against each individual fault. n After enhancements, infinite set of unexpected faults still remain and can disable the system. l Enhancements add complexity n Each enhancement opens new attacks. –Ex: Deployment of PKI based route checking opens issues of faults and attacks at the new PKI.

31. 4 June 0331masseyd@isi.edu Security and Resiliency l Resiliency: capable of withstanding shock without permanent deformation or rupture, can recover from failure, attack, change. l Components in Resiliency n Prevention –cryptographic-based security mechanisms n Adding detection capability into protocol design –Be liberal in what you receiver, but conservative in what you believe –add additional information to enable protocols to verify the validity of information carried in the packet n Adding reaction into the systems –Fault identification leads to corrective action

32. 4 June 0332masseyd@isi.edu Resiliency-Oriented Design 1. Designing resiliency into network protocols 2. Building multi-fences against faults n In functionality design: avoiding duplication of functionality at multiple layers n In resiliency design: the more fences, the higher resiliency n Can we build levels of innate immunity into the system?

33. 4 June 0333masseyd@isi.edu Lessons From Related Fields l Consider how biological system incorporates both specific and innate immunity. n Learn from the faults you encounter or expect to encounter to achieve specific immunity. –Current state of protocol design starting to do this. n Provide innate immunity against some yet unknown threats –Will never provide perfect protection –But does succeed in general protection of the system –This concept of general protection has yet to be considered for network protocols.

34. 4 June 0334masseyd@isi.edu Some Preliminary Results l At a very fundamental level, all applications rely on packet delivery service provided by the IP routing "The top stones of a pyramid have to support only their own weight, while the bottom blocks support the weight of all the stones above it" l Our initial effort focused on routing protocols n Add fault-tolerance to RIP - submitted to GlobeCom 2003 n Add fault-tolerance to BGP - DSN 2002 result n Speed up global routing convergence - Infocom 2001 n Improved packet delivery - (to appear in) DNS 2003

35. 4 June 0335masseyd@isi.edu Can RIP Detect False Updates? l Each node only knows the distance to immediate neighbor nodes l Even that limited knowledge can still be used to perform certain validity check n Had the ARPANET routing built this check in, the black-hole event would have been prevented

36. 4 June 0336masseyd@isi.edu BGP Update Verification l A advertises network R to both B & D l When A withdraws route to reach R, n Current implementation: B will attempt to go through C to reach R till the route converges n Path verification: upon receiving the withdraw update from A, B can recognize immediately that A is also on the path to R through C  declare C’s path to R invalid B A D C R

37. 4 June 0337masseyd@isi.edu Multi-Origin AS Routing Announcement l MOAS exists in current BGP operation n Some due to operational need; some due to faults l Blind acceptance of MOAS dangerous n An open door for traffic hijacking

38. 4 June 0338masseyd@isi.edu BGP-based Solution Example 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

39. 4 June 0339masseyd@isi.edu (b) Two Origin AS’s(a) One Origin AS BGP false origin detection Simulation Results

40. 4 June 0340masseyd@isi.edu What To Take Away l A new look at the Internet infrastructure n Scaling up has more profound implications beyond bigger numbers/tables. l Adding Authentications n Some details of DNSSEC and why it is not trivial. l Need for more than just cryptography n Motivation to look at research challenges in designing secure and resilient protocols.