designing a secure and resilient internet infrastructure dan massey usc/isi

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


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.


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”.


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


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


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


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


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

http://www.darpa.mil/


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.


A Simple DNS Attack

Caching DNS Server

Sanjoy’s Laptop

www.darpa.mil A?


Root DNS Server

mil DNS Server


Dan’s Laptop

Easy to observe UDP DNS query sent to well known server on well known port.


First response wins. Second response is silently dropped on the floor.


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


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.


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.


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


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


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


There is no magic fairy dust


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?


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


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


Revised DNS Key Management

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


DNS Key Roll-Over

mil DNS Server











Objective: Replace KEY 1 with new KEY 3


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.


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.


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.


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


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


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


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?


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.


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.


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


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.


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


(b) Two Origin AS’s(a) One Origin AS

BGP false origin detection

Simulation Results


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.

designing a secure and resilient internet infrastructure dan massey usc/isi

Documents

dns root servers

root dns serveractually

responsecaching dns

mil dns

false root server

false bgp routes

false server

root server attack example