Designing a Secure and Resilient Internet Infrastructure

1
Designing a Secure and Resilient Internet
Infrastructure

• Dan Massey
• USC/ISI

2
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

3
Internet Infrastructure

• Internet relies on fundamental infrastructures
• BGP Internet Routing Protocol
• DNS Internet Naming Service
• Failure at these levels often cant 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.

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

5
A More Interesting Example

• Invalid BGP routes exist in everyones table.
• These can include routes to root/gTLD servers
• One example observed on 4/16/01

originates route to 192.26.92/24
ISPs announce new path 3 lasted 20 minutes 1
lasted 3 hours
Internet
c.gtld-servers.net
192.26.92.30
rrc00 monitor
6
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
Internet Routing
Spoofed Root server
Root server
7
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
8
The Domain Name System

• Virtually every application uses the Domain Name
  System (DNS).
• DNS database maps
• Name to IP addresswww.darpa.mil 128.9.176.20
• And many other mappings (mail servers, IPv6,
  reverse)
• Data organized as tree structure.
• Each zone is authoritativefor its local data.

Root
edu
mil
com
darpa
isi
cisco
usmc
nge
quantico
9
DNS Query and Response
www.darpa.mil A?
Root DNS Server
www.darpa.mil A 128.9.128.127
Caching DNS Server
End-user
mil DNS Server
Actually www.darpa.mil 192.5.18.195. But how
would you determine this?
darpa.mil DNS Server
10
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.

11
A Simple DNS Attack
Easy to observe UDP DNS query sent to well known
server on well known port.
www.darpa.mil A?
Root DNS Server
www.darpa.mil A 192.5.18.19
Sanjoys Laptop
Caching DNS Server
www.darpa.mil A 128.9.128.127
mil DNS Server
Dans Laptop
First response wins. Second response is silently
dropped on the floor.
darpa.mil DNS Server
12
A More Complex Attack
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
Bell Labs Caching Server
www.google.com 128.9.128.127
ns.attacker.com
Query www.attacker.com
Query www.google.com
Any Bell Labs Laptop
Remote attacker
13
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.

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

15
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.
Challenge add signatures to the protocol
manage DNS public keys
16
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 )
17
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
18
There is no magic fairy dust
19
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.
• Authenticated denial of existence? or security?

20
Bush, Griffin, Meyer draft-ymbk-arch-guidelines-0
3.txt
Lesson Simple Operations

Mike ODell
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).
The implication for carrier IP networks then, is
that to be successful we must drive our
architectures and designs toward the simplest
possible solutions.
21
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
KEY set P1
Select KEY set C1
Sign KEY set C1 with P1
KEY set C1 and SIG(P1) entered in child zone
Select KEY set P2 and sign KEY set C1
Add SIG(P2) to child zone
Replace P1 with P2
Remove SIG(P1) to child zone
22
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)
darpa.mil SIG(A) by key 1
Can Change key 2 without notifying .mil
www.darpa.mil A record
www.darpa.mil SIG(A) by key 2
23
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
darpa.mil KEY (pub key 1)
Objective Replace KEY 1 with new KEY 3
darpa.mil KEY (pub key 2)
darpa.mil KEY (pub key 3)
darpa.mil SIG(A) by key 1
darpa.mil SIG(A) by key 3
24
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.

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

26
Authenticated Denial of Existence

• What if the requested record doesnt exist?
• Query for foo.ucla.edu returns No such name
• How do you authenticate this?
• Operations impose challenges.
• Cant predict user would ask for foo.ucla.edu
• Cant sign reply on the fly
• Query may go to any of serveral servers
• You dont trust all servers with the private key.
• Ex nge.isi.edu master server is at ISI, but
  secondaries are at UCL (London) and USC.

27
NXT Records
Challenge Prove name does not exist given that
you cant predict what user might ask
you dont trust authoritative server with private
key
Caching DNS Server
Foo.lucent.com. ?
Authoritative DNS Servers
End-user
foo.lucent.com. does not exist Some sort of
signature to needed.
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 .
28
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
• ProposedEach signed name in com needs an NXT
  and SIG
• IETF debate concluding. (hopefully!)

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

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

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

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

33
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

34
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 cant
  block valid lists in an Internet topology.

35
Non-cryptographic BGP Security
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
36
BGP false origin detection

• Simulation Results

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