Security and Resilience for the Internet Infrastructure

1
Security and Resilience for the Internet
Infrastructure

• Dan Massey
• USC/ISI

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

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

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

6
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.
• Todays Internet infrastructure works due to
• Innate ability to handle fail-stop faults.
• Clever operators to handle everything else.

7
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.
8
The Internet Change in Size
the Internet continues to grow both in size and
in importance

• 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

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

10
Actual Potential for Disaster

• BGP Provides No Authentication
• Faults and attacks can mis-direct traffic.
• One (of many) examples observed from BGP logs.

originates route to 192.26.92/24
ISPs announced new path for 20 minutes to 3 hours
Internet
c.gtld-servers.net
192.26.92.30
BGP monitor
11
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 Doesnt 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.

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

13
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
14
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.

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

16
Secure DNS Query and Response
Caching DNS Server
www.darpa.mil
Authoritative DNS Servers
www.darpa.mil
192.5.18.195 Plus (RSA) signature by darpa.mil
End-user
Attacker can not forge this answer without the
darpa.mil private key.
17
Example of Signed Record
name TTL class SIG type_covered
algorithm
labels_in_name original_TTL
expiration and inception dates
key tag
key name
signature
zen.nge.isi.edu. 82310 IN A
65.114.169.197 zen.nge.isi.edu. 86400 IN SIG
A 1 5 86400 20030226023910 (
20030127023910 468
nge.isi.edu.
2gHZzvcB01VSnjF9K0eet1sUQrGprMZC1Kn
FNLSeJMMjN0Aw4Ewj5I
l8ejvqO0lXnjNOo
EzlhXAVmp5dT0WjJB78Nv51UEHW0bQnt05

PQ86nXaTTXXQyYE3PSrmASfwXyVlXh430ty3
oWZUZdBZUgvqRGT97xLtagd
rCq0 )
18
Example Public Key
name TTL class KEY FLAGS PROTOCOL Algorithm
public key
nge.isi.edu. 82310 IN KEY 256 3 1 (
2gHZzvcB01VSnjF9K0e
et1sUQrGprMZC1Kn
FNLSeJMMjN0Aw4Ewj5Il8ejvqO0lXnjNOo

EzlhXAVmp5dT0WjJB78Nv51UEHW0bQnt05 nge.isi.edu.
86400 IN SIG KEY 1 3 86400 20030226023910
(
20030127023910 569 isi.edu.
2gHZzvcB01VSnjF9K0eet1sUQrGprM
ZC1Kn
FNLSeJMMjN0Aw4Ewj5Il8ejvqO0lXnjNOo
EzlhXAVmp5dT0WjJB78Nv
51UEHW0bQnt05
PQ86nXaTTXXQyYE3PSrmASfwXyVlXh430ty3
oWZUZdBZUgvqRGT97xL
tagdrCq0 )
Note nge.isi.edu KEY is signed by isi.edu private
key
19
There is no magic fairy dust
20
So Why Arent 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.

21
Revised DNS Key Management
darpa.mil NS records
Can Change mil key without notifying darpa.mil
darpa.mil DS record (hash of pubkey 1)
darpa.mil SIG(DS) by mil private key
mil DNS Server
darpa.mil DNS Server
darpa.mil KEY (pub key 1)
darpa.mil KEY (pub key 2)
Use key 2 only to limit interactions with
.mil Note you can change key 2 Without notifying
mil
darpa.mil SIG(A) by key 1
www.darpa.mil A record
www.darpa.mil SIG(A) by key 2
22
DNS Key Roll-Over
darpa.mil DS record (hash of pubkey 3)
darpa.mil SIG(DS) by mil private key
darpa.mil DS record (hash of pubkey 1)
darpa.mil SIG(DS) by mil private key
mil DNS Server
darpa.mil DNS Server
Objective Replace KEY 1 with new KEY 3
darpa.mil KEY (pub key 1)
darpa.mil KEY (pub key 3)
darpa.mil SIG(A) by key 1
darpa.mil SIG(A) by key 3
23
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.

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

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

26
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 (Peress Law)
27
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.

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

It is time we start a proactive, systematic
approach to Internet resiliency
29
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

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

31
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

32
Resiliency-Oriented Design

• Designing resiliency into network protocols
• Building multi-fences against faults
• In functionality design avoiding duplication of
  functionality at multiple layers
• In resiliency design the more fences, the higher
  resiliency
• Can we build levels of innate immunity into the
  system?

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

34
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

35
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

36
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 Cs
  path to R invalid

B
C
A
D
R
37
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

38
BGP-based Solution Example
AS58
18.0.0.0/8
AS52
AS59
Example configuration
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 out route-map
setcommunity match ip address 18.0.0.0/8 set
community 59MOAS 58MOAS additive
39
BGP false origin detection

• Simulation Results

(b) Two Origin ASs
(a) One Origin AS
40
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.