Upload
brianna-bond
View
217
Download
0
Tags:
Embed Size (px)
Citation preview
Designing a Secure and Resilient Internet Infrastructure
Dan MasseyUSC/ISI
2 May 03 [email protected]
Overview
Internet Infrastructure
Overview and Vulnerabilities
Securing the Domain Name System
IETF Standard for Authentication of DNS
Responses
Critical Failures and Lessons Learned
Open Challenges for Infrastructure Security
2 May 03 [email protected]
Internet Infrastructure
Internet relies on fundamental infrastructures BGP Internet Routing Protocol DNS Internet Naming Service
Failure at these levels often can’t be overcome. Provide basic packet delivery functions.
Protocol Designs Show Signs of Age Growing complexity of large-scale systems. Demand for new features and services. Primarily designed for only fail-stop faults. Little or no protection against malicious attacks.
2 May 03 [email protected]
Example Infrastructure Problems
BGP Routing Fault Example: ISP mistakenly announced routes to 3000+
prefixes (destinations) it did not own. Other ISPs adopt these routes and
blackholed traffic to those sites. DNS Root Server Attack Example:
Recent DDoS attack disabled majority of the 13 DNS root servers.
Bringing down all 13 root servers is frequently mentioned as a worst case scenario that would “cripple the Internet”.
2 May 03 [email protected]
A More Interesting Example
InternetInternet c.gtld-servers.net
rrc00 monitor
192.26.92.30
originates route to 192.26.92/24
Invalid BGP routes exist in everyone’s table. These can include routes to root/gTLD servers One example observed on 4/16/01:
ISPs announce new path3 lasted 20 minutes
1 lasted 3 hours
2 May 03 [email protected]
The Potential Catastrophic Attack
BGP routing can direct packets to false server.
Detected false BGP routes to root/gTLD severs at major global ISPs. Routes lasted up to hours,
but were errors and faulty site did not reply.
Any response from false server would be believed. NANOG 25/ICDCS 2003 -
protecting BGP routes to DNS servers
Bell Labs Caching Server
Root serverSpoofed
Root server
Internet Routing
2 May 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
2 May 03 [email protected]
Virtually every application uses
the Domain Name System (DNS).
DNS database maps:
Name to IP address
www.darpa.mil = 128.9.176.20
And many other mappings
(mail servers, IPv6, reverse…)
Data organized as tree structure.
Each zone is authoritative
for its local data.
Root
edu mil com
darpaisi ciscousmc
nge quantico
The Domain Name System
2 May 03 [email protected]
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?
mil DNS Server
darpa.mil DNS Server
2 May 03 [email protected]
DNS Vulnerabilities
Original DNS design focused on data availability
DNS zone data is replicated at multiple servers.
A DNS zone works as long as one server is available.
– DDoS attacks against the root must take out 13 root servers.
But the DNS design included no authentication.
Any DNS response is generally believed.
No attempt to distinguish valid data from invalid.
– Just one false root server could disrupt the entire DNS.
2 May 03 [email protected]
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.
2 May 03 [email protected]
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
2 May 03 [email protected]
The Problem in a Nutshell
Resolver can not distinguish between
valid and invalid data in a response.
Idea is to add source authentication
Verify the data received in a response is equal
to the data entered by the zone administrator.
Must work across caches and views.
Must maintain a working DNS for old clients.
2 May 03 [email protected]
Authentication 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.
2 May 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
Challenge: add signatures to the protocol manage DNS public keys
2 May 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
2 May 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
2 May 03 [email protected]
There is no magic fairy dust
2 May 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. Authenticated denial of existence? or
security?
2 May 03 [email protected]
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 03 [email protected]
RFC 2535 Key Change Process
Signatures from parent zone sit in child zone. Requires some sync
between parent/child Figure shows process
of a key change at edu.
Actual exchange is much more complex. “com” change
assumes rough sync shown here at 22 million different zones
ucdavis.edu edu
Select KEYset C1 Sign KEY
set C1
with P1
KEY set P1
KEY set C1
and SIG(P1)entered in child zone
Select KEYset P2 andsign KEY
set C1
Replace P1
with P2
Add SIG(P2)to child zone
Remove SIG(P1)to child zone
2 May 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
Can Change key 2 without notifying .mil
2 May 03 [email protected]
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 03 [email protected]
Minimal Requirements
Parent must indicate how to reach the
child.
NS records at parent MUST identify at least
one valid name server for child.
Parent must identify a trusted key at child.
DS record at parent MUST match a valid KEY
stored at the child.
2 May 03 [email protected]
Lesson: Protocol Complications
Building on an existing system
Objective is to strengthen the system.
But additions also add stress to weak
points.
Some example cases:
Denial of service added by the DS record.
NS records stored at the parent.
Over use of the KEY record.
2 May 03 [email protected]
Authenticated Denial of Existence
What if the requested record doesn’t exist? Query for foo.ucla.edu returns “No such name” How do you authenticate this?
Operations impose challenges. Can’t predict user would ask for “foo.ucla.edu” 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 03 [email protected]
NXT Records
Caching DNS Server
End-user
Foo.lucent.com. ?
foo.lucent.com. does not existSome 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 03 [email protected]
The Opt-In Proposal
Change the semantics of the NXT record. Current: next name after “a” is “c” Proposed: next signed name after “a” is “c”
Provides Gradual Roll-Out Inside a Zone Current:
Each name in com needs an NXT and SIG Proposed:
Each signed name in com needs an NXT and SIG
IETF debate concluding…. (hopefully!)
2 May 03 [email protected]
Status Of DNSSEC
Opt-In/authenticated denial remains issue…. “com” to deploy within 6 months if yes on Opt-In Several TLDs ready to deploy. Working with DARPA/USMC.mil on deployment
Only minor issues remain in spec IETF DNSEXT working group drafts:
– Intro to DNSSEC, DNSSEC Records, DNSSEC Protocol
Comments welcome
Opens the door for new challenges….
2 May 03 [email protected]
New DNSSEC Decisions
DNSSEC works well in a logical case What really happens when DNSSEC fails? Bridging incremental deployment?
Test sites quickly abandoned strict model Sites configured servers to accept unsigned data
even when signed expected. Sites quickly configured servers to ignore some
authentication failures. (expired signatures) General rule: DNS prefers some answer
(even if it fails crypto) to no answer. What does this mean for the security model?
2 May 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.
2 May 03 [email protected]
Securing BGP
Secure BGP (S-BGP) proposes to add public key cryptography to BGP. Replace DNS with BGP. Repeat previous
slides. Secure DNS and BGP are essential. But even when successful, secure
BGP/DNS are only part of the solution. New complexity due to authentication. Failures in the authentication. New denial of serivice issues. Insider attacks.
2 May 03 [email protected]
General Infrastructure Security Revisit protocol design given challenges
of: New services (ex: dynamic DNS) New tools (ex: DNSSEC) New requirements (DNS as the PKI??) More scale & complexity (more in
routing/BGP) Multi-fence approach to protocol design
Incorporate cryptography as part of the solution.
Can also achieve resilience throught protocol design without cryptography
2 May 03 [email protected]
Two Examples of New Fences
Identify inherent consistency requirements: BGP routes include a path to the destination
and paths must be self-consistent. INFOCOM 02: reject inconsistent paths to avoid
false routes. Add consistency when possible.
BGP allows multiple origins, making it difficult to distinguish valid origins from false origins.
Our fix: list all valid origins in the route update. DSN 02: attacker can forge the list, but can’t
block valid lists in an Internet topology.
2 May 03 [email protected]
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 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
2 May 03 [email protected]
(b) Two Origin AS’s(a) One Origin AS
BGP false origin detection
Simulation Results
2 May 03 [email protected]
What To Take Away
A new look at the Internet infrastructure
Real practical need to have solutions now.
Adding Cryptography
Some details of DNSSEC and a view of why
it is not a trivial problem.
Need for more than just cryptography
Motivation to look at research challenges
in designing secure and resilient protocols.