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

Click here to load reader

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of Security and Resilience for the Internet Infrastructure Dan Massey USC/ISI

  • Slide 1
  • Security and Resilience for the Internet Infrastructure Dan Massey USC/ISI
  • Slide 2
  • 4 June [email protected] 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)
  • Slide 3
  • 4 June [email protected] 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
  • Slide 4
  • 4 June [email protected] 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.
  • Slide 5
  • 4 June [email protected] 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.
  • Slide 6
  • 4 June [email protected] 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 Todays Internet infrastructure works due to Innate ability to handle fail-stop faults. Clever operators to handle everything else.
  • Slide 7
  • 4 June [email protected] 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.
  • Slide 8
  • 4 June [email protected] 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
  • Slide 9
  • 4 June [email protected] 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.
  • Slide 10
  • 4 June [email protected] Actual Potential for Disaster Internet BGP monitor 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
  • Slide 11
  • 4 June [email protected] 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 Doesnt 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.
  • Slide 12
  • 4 June [email protected] 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.
  • Slide 13
  • 4 June [email protected] 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
  • Slide 14
  • 4 June [email protected] 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.
  • Slide 15
  • 4 June [email protected] 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.
  • Slide 16
  • 4 June [email protected] Secure DNS Query and Response Caching DNS Server End-user = Plus (RSA) signature by Attacker can not forge this answer without the private key. Authoritative DNS Servers
  • Slide 17
  • 4 June [email protected] Example of Signed Record 82310 IN A 86400 IN SIG A 1 5 86400 20030226023910 ( 20030127023910 468 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
  • Slide 18
  • 4 June [email protected] Example Public Key 82310 IN KEY 256 3 1 ( 2gHZzvcB01VSnjF9K+0eet1sUQrGprMZC1Kn FNLSeJMMjN0Aw4Ewj5+Il8ejvqO0lX+njNOo EzlhXAV+mp5dT0WjJB+78Nv51UEHW0bQnt05 86400 IN SIG KEY 1 3 86400 20030226023910 ( 20030127023910 569 2gHZzvcB01VSnjF9K+0eet1sUQrGprMZC1Kn FNLSeJMMjN0Aw4Ewj5+Il8ejvqO0lX+njNOo EzlhXAV+mp5dT0WjJB+78Nv51UEHW0bQnt05 PQ86nXaTTXXQyYE3PSrmASfwXyVlXh430ty3 oWZUZdBZUgvqRGT97xLtagdrCq0= ) name TTL class KEY FLAGS PROTOCOL Algorithm public key Note KEY is signed by private key
  • Slide 19
  • 4 June [email protected] There is no magic fairy dust
  • Slide 20
  • 4 June [email protected] So Why Arent 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.
  • Slide 21
  • 4 June [email protected] Revised DNS Key Management mil DNS Server DNS Server NS records A record SIG(A) by key 2 KEY (pub key 1) KEY (pub key 2) SIG(A) by key 1 DS record (hash of pubkey 1) SIG(DS) by mil private key Can Change mil key without notifying Use key 2 only to limit interactions Note you can change key 2 Without notifying mil
  • Slide 22
  • 4 June [email protected] DNS Key Roll-Over mil DNS Server DNS Server KEY (pub key 1) SIG(A) by key 1 DS record (hash of pubkey 1) SIG(DS) by mil private key KEY (pub key 3) SIG(A) by key 3 DS record (hash of pubkey 3) SIG(DS) by mil private key Objective: Replace KEY 1 with new KEY 3
  • Slide 23
  • 4 June [email protected] 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.
  • Slide 24
  • 4 June [email protected] A More Rea