Designing a Secure and Resilient Internet Infrastructure Dan Massey USC/ISI

Designing a Secure and Resilient Internet Infrastructure

Dan MasseyUSC/ISI

2 May 03 2masseyd@isi.edu

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 3masseyd@isi.edu

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 4masseyd@isi.edu

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 5masseyd@isi.edu

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 6masseyd@isi.edu

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

2 May 03 8masseyd@isi.edu

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 9masseyd@isi.edu

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 10masseyd@isi.edu

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 11masseyd@isi.edu

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 12masseyd@isi.edu

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 13masseyd@isi.edu

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 14masseyd@isi.edu

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 15masseyd@isi.edu

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 16masseyd@isi.edu

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 17masseyd@isi.edu

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 18masseyd@isi.edu

There is no magic fairy dust

2 May 03 19masseyd@isi.edu

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 20masseyd@isi.edu

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 21masseyd@isi.edu

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 22masseyd@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

Can Change key 2 without notifying .mil

2 May 03 23masseyd@isi.edu

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 24masseyd@isi.edu

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 25masseyd@isi.edu

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 26masseyd@isi.edu

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 27masseyd@isi.edu

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 28masseyd@isi.edu

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 29masseyd@isi.edu

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 30masseyd@isi.edu

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 31masseyd@isi.edu

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 32masseyd@isi.edu

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 33masseyd@isi.edu

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 34masseyd@isi.edu

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 35masseyd@isi.edu

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 36masseyd@isi.edu

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

BGP false origin detection

Simulation Results

2 May 03 37masseyd@isi.edu

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.