Security and Resilience for the Internet Infrastructure Dan Massey USC/ISI.
-
date post
21-Dec-2015 -
Category
Documents
-
view
215 -
download
1
Transcript of Security and Resilience for the Internet Infrastructure Dan Massey USC/ISI.
4 June 03 [email protected]
Acknowledgements Research Funding Sources
NSF Beyond BGP Project DARPA FNIISC Project DARPA FMESHD Project
Current Research Team Members Lixia Zhang, Lan Wang, Dan Pei, Mohit Lad
(UCLA) Felix Wu (UC Davis) & Xiaoliang Zhao (USC/ISI)
New Collaborations Andreas Terzis (John Hopkins) & Songwu Lu
(UCLA)
4 June 03 [email protected]
Overview
The Current Internet Infrastructure
System Overview and Current Threat Model
New Challenges to the Infrastructure.
Dramatic change in scale and behavior.
Current Approach to Enhancements
Called security, but really authentication
The Multiple-Fence Approach
4 June 03 [email protected]
Internet Infrastructure Definition
Provides Fundamental Communication
Services. Necessary (not sufficient) for applications to work.
Internet Infrastructure Protocols Include: DNS Internet Naming Protocol
BGP Inter-Domain Internet Routing Protocol
For Generic Application X Use DNS to translate name into IP address
BGP provides reachability to IP address.
4 June 03 [email protected]
The Current Fault Model Assume any number of fail-stop faults occur.
Any link, router, or server can stop operating. BGP Routing Works Despite Faults
Rich topology provides multiple potential paths.– Increasing drive toward multi-homing
Adapt to any combination of link/router failure.– With on-going work on improving convergence.
DNS Naming Works Despite Faults DNS data replicated at multiple servers. Automatically detect and avoid failed servers.
4 June 03 [email protected]
Coping With Unexpected Faults
Protocols expect only fail-stop faults.
Examples of other faults are well known Original ARPANET routing malfunction
– East coast router reports 0 distance route to UCLA
Revised ARPANET routing complex behavior
– Unexpected sequence number combination.
Rely on ad-hoc manual solutions to recover. Today’s Internet infrastructure works due to
– Innate ability to handle fail-stop faults.
– Clever operators to handle everything else.
4 June 03 [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.”
4 June 03 [email protected]
The Internet Change in Size
Wider range of heterogeneity Larger traffic volume Bigger routing tables Higher failure frequency But most importantly:
ever increasing new threats due to growing large ever increasing complexity due to growing large
the Internet continues to grow both in size and in importance
4 June 03 [email protected]
The Fail-Stop View of Disaster Well known DNS “root server problem”
DNS is a tree structure and queries start at root. 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
Loss of all 13 root servers would cripple DNS Counter measures to the root server problem.
Servers on high bandwidth links. Strong network and server administration. Close monitoring to detect attacks.
– Lost majority to DDoS, but have never lost all servers.
4 June 03 [email protected]
Actual Potential for Disaster
InternetInternet c.gtld-servers.net
BGP monitor
192.26.92.30
originates route to 192.26.92/24
BGP Provides No Authentication Faults and attacks can mis-direct traffic. One (of many) examples observed from BGP
logs.
ISPs announced new pathfor 20 minutes to 3 hours
4 June 03 [email protected]
A Different View of Disaster
Inter-component Complexity Problems Provided strong protection for real root/gTLD servers.
But overlooked routes leading to these servers.
Limitations of the Fail-Stop Model Assume BGP router announces legitimate routes.
Assumed DNS server replies with valid data.
Simply Scaling Up the Infrastructure Doesn’t Work Proposal to increase number of root servers
– Use anycast to overcome some protocol restrictions.
But change in size requires change in form.– Must maintain data integrity between more root servers.
4 June 03 [email protected]
Size Change Design Change
The Internet's large change in size calls for a fundamental change in network protocol design considerations. NANOG 28: One operator detected over
5000 compromised routers between Jan 1 - May 31
NANOG 28: One ISP detected compromise of its entire backbone.
Realistic Threat Model Must Assume Not all the components will play by the
rules. Things can go wrong in unexpected ways.
4 June 03 [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
4 June 03 [email protected]
New Infrastructure Enhancements Problem: BGP and DNS lack authentication.
Easy to insert false BGP routes. Easy to reply with false DNS data
Add Public Key Authentication to BGP. Verify origin is authortized to announce prefix. Verify each link in the AS path. Requires some PKI structure.
Add Public Key Authentication to DNS DNSSEC further along than BGP approaches DNS provides lessons for BGP authentication.
4 June 03 [email protected]
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 in the DNS heirarchy.
4 June 03 [email protected]
Secure DNS Query and Response
Caching DNS Server
End-user
www.darpa.mil
www.darpa.mil = 192.5.18.195Plus (RSA) signature by darpa.mil
Attacker can not forge this answer without the darpa.mil private key.
Authoritative DNS Servers
4 June 03 [email protected]
Example of Signed Record
zen.nge.isi.edu. 82310 IN A 65.114.169.197zen.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
4 June 03 [email protected]
Example Public Key
nge.isi.edu. 82310 IN KEY 256 3 1 ( 2gHZzvcB01VSnjF9K+0eet1sUQrGprMZC1Kn FNLSeJMMjN0Aw4Ewj5+Il8ejvqO0lX+njNOo EzlhXAV+mp5dT0WjJB+78Nv51UEHW0bQnt05nge.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 signedby isi.edu private key
4 June 03 [email protected]
So Why Aren’t We There Yet Scope of DNS security too broad
Attempt to solve DNS security and build generic global PKI at same time.
RFC 2535 design was fatally flawed. Key management did not scale and did
not work in realistic operations. Progress on Improving DNSSEC.
RFC 3449 now limits scope to secure DNS.
Revised DNS key management system implemented and verified at workshops.
4 June 03 [email protected]
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 2Without notifying mil
4 June 03 [email protected]
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
4 June 03 [email protected]
Deployment Experience DNSSEC works well in a logical case
But what really happens when DNSSEC fails? How do we bridging incremental deployment?
Security Model Evolved in Practice Started with a strict model to only accept signed
responses (or accept a proof the zone was not signed).
But sites configured servers to ignore some authentication failures (expired signatures) and accept unsigned data even when signed expected.
Authentication in the Infrastructure is Different DNS prefers some questionable answer to no
answer. Same rule will applies to BGP.
4 June 03 [email protected]
A More Realistic View of DNSSEC
Adding security is a non-trivial problem. Over 10 years of DNSSEC work, no
deployment DNSSEC is not the complete answer.
No defense against denial of service. More incremental deployment work
needed. DNSSEC enables many new features.
Management of root zones. New tool (one of many) for achieving truly
robust DNS infrastructure.
4 June 03 [email protected]
The Role of Authentication Secure DNS/BGP add authentication.
Authentication is not equivalent to security. And adds new denial of service attacks.
Very Effective in Some Scenarios Can prefer authenticated data over other data.
– Forces attacker to block authenticated data. But attacker can block authenticated data.
– Misconfigurations, older implementations also block. Authentication primarily enables new
services. Ex: can increase number of DNS root servers. Ex: can better trace the source of a
fault/attack.
4 June 03 [email protected]
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”)
4 June 03 [email protected]
Protocol Design for Simple Functionality
Contain the minimal set of bits necessary for data delivery
Explicitly enumerates all possible physical failures Node failure: fail stop
Link failure: disconnect
Data delivery failure: bit error, our of order, loss, duplicates
Implicitly assumes that Every component follows the rules
No faults other than physical failures listed above.
4 June 03 [email protected]
Increased Fault Detection in Practice
As reactions to the hostile reality DHCP user authentication DoS block boxes
Packet washing machine - ex: Riverhead Networks
ISP traffic filtering Strongly encourage filtering at the edges.
TTL checking Filtering out attack traffic Filtering out bogus BGP messagesIt is time we start a proactive, systematic approach to Internet resiliency
4 June 03 [email protected]
Improving the Fault Response New enhancements address specific faults Example: overload attack at router CPU
Frequent (daily) problem for AOL routers. Solution: check TTL and only allow control traffic
from one hop away. Example: false route announcements
Common due to operational errors Solution: apply cryptography and PKI to check
the origin AS is authorized to announce the prefix. Many other enhancements driven by known
faults Ranging from performance to convergence to
security
4 June 03 [email protected]
Fault-Driven Limitations
The potential space of faults/attacks is vast. Not possible to list and engineer against each
individual fault. After enhancements, infinite set of
unexpected faults still remain and can disable the system.
Enhancements add complexity Each enhancement opens new attacks.
– Ex: Deployment of PKI based route checking opens issues of faults and attacks at the new PKI.
4 June 03 [email protected]
Security and Resiliency Resiliency:
capable of withstanding shock without permanent deformation or rupture, can recover from failure, attack, change.
Components in Resiliency Prevention
– cryptographic-based security mechanisms 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 Adding reaction into the systems
– Fault identification leads to corrective action
4 June 03 [email protected]
Lessons From Related Fields Consider how biological system incorporates
both specific and innate immunity. Learn from the faults you encounter or expect to
encounter to achieve specific immunity.– Current state of protocol design starting to do this.
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.
4 June 03 [email protected]
Some Preliminary Results 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"
Our initial effort focused on routing protocols Add fault-tolerance to RIP - submitted to
GlobeCom 2003 Add fault-tolerance to BGP - DSN 2002 result Speed up global routing convergence - Infocom
2001 Improved packet delivery - (to appear in) DNS
2003
4 June 03 [email protected]
Can RIP Detect False Updates? Each node only knows the distance to
immediate neighbor nodes Even that limited knowledge can still be
used to perform certain validity check Had the ARPANET routing built this check in, the
black-hole event would have been prevented
4 June 03 [email protected]
BGP Update Verification A advertises network R to both
B & D When A withdraws route to
reach R, Current implementation: B will
attempt to go through C to reach R till the route converges
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
AD
C
R
4 June 03 [email protected]
Multi-Origin AS Routing Announcement
MOAS exists in current BGP operation Some due to operational need; some due to faults
Blind acceptance of MOAS dangerous An open door for traffic hijacking
4 June 03 [email protected]
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 outroute-map setcommunity match ip address 18.0.0.0/8 set community 59:MOAS 58:MOAS additive
Example configuration:
AS58
18/8, PATH<4>, MOAS{4,58,59}
AS59
18.0
.0.0
/8 18/8, PATH<58>, MOAS{58,59}
18/8, PATH<59>, MOAS{58,59}
18/8, PATH<52>, MOAS{52, 58}
AS52
4 June 03 [email protected]
(b) Two Origin AS’s(a) One Origin AS
BGP false origin detectionSimulation Results
4 June 03 [email protected]
What To Take Away
A new look at the Internet infrastructure
Scaling up has more profound implications
beyond bigger numbers/tables.
Adding Authentications
Some details of DNSSEC and why it is not trivial.
Need for more than just cryptography
Motivation to look at research challenges in
designing secure and resilient protocols.