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

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

Security and Resilience for the Internet Infrastructure

Dan MasseyUSC/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]

There is no magic fairy dust

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.