Facilitating Secure Internet Infrastructure · 2008. 4. 23. · A Foundation for Routing Security • The use of authenticatable attestations to allow automated validation of: -

http://www.ripe.net

RIPE Network Coordination Centre

Facilitating Secure Internet Infrastructure

Andrei Robachevsky RIPE NCC

http://www.ripe.net


Security Forum, April 23, 2008 2 Andrei Robachevsky

About the RIPE NCC

• Bottom-up, self-regulated, membership association, not-for-profit

• Regional Internet Registry - Allocation of IP addresses and AS numbers - Reverse DNS

• Network Coordination Centre - Information Services, Coordination activities

• Funded entirely by members; fully autonomous

Open Transparent Neutral Impartial

• RIPE NCC is not RIPE

http://www.ripe.net



Regional Internet Registries (RIRs)

1992

1993

1997

2002

2005

http://www.ripe.net



The presenter

• Chief Technical Officer - General IT - On-line Services • RIPE Database • DNS & K-root • Information Services

- Inter-RIR technical coordination

• Not a security expert, but - Coordinated deployment of DNSSEC at the RIPE NCC - Active participant in resource certification activities

http://www.ripe.net



Thanks

• Olaf Kolkman and Jaap Akkerhuis from NLNetLabs • Geoff Huston from APNIC • Daniel Karrenberg from RIPE NCC

- For allowing me to steal their slides

• RIPE NCC and other RIR teams - For doing the actual work

• The Security Forum - For inviting me

http://www.ripe.net



Outline

• Security and the Internet

• Security and DNS

• Security and Routing

• Challenges

http://www.ripe.net



There are many ways to be bad on the Internet

• Enlist a Bot army and mount multi-gigabit DOS attacks - Extortion leverage

• Port Scan for known exploits - Deploy a bot, spyware or simply annoy people

• Spew spam - Yes, there are still gullible folk out there!

• Mount a fake web site attack - And lure victims

• Mount a routing attack - And bring down an entire service / region / country / global network!

http://www.ripe.net



Internet Architecture

• A Network of Networks - Little intelligence inside the network - Most of the intelligence is in the end-systems • Adding functionality doesn’t require network changes • Adding security doesn’t require network changes

• Between Networks - Routing & Addressing - Domain Name System - Introducing changes here is more challenging

http://www.ripe.net



Securing the Internet

• Securing the Infrastructure - Cables, routers, power, colo’s, etc.

• Securing the edges - Servers, PCs, etc.

• Securing the “between” - The common good

http://www.ripe.net



Network Infrastructure

• Little intelligence - Little potential for exploitation and abuse

• Key business assets for ISPs - Lots of motivation for security

• Clear responsibility • Challenges

- Can be done locally and incrementally - Not a big problem

http://www.ripe.net



The end-systems

• Hosts, personal computers, servers - Intelligence here: a versatile abuse toolkit - Poorly defended: design flaws and lack of expertise - Increasing bandwidth: effective weapon - Responsibility: widely dispersed - Criminal activities: botnets, etc.

• Challenges - Cannot be done centrally - Little control and responsibility - Buggy applications - Growing number

http://www.ripe.net



The between - the common good

• Routing - Decentralised - Addressing - hierarchical

• DNS - Hierarchical, distributed

• Challenges - Responsibility is dispersed - Cannot be done centrally - Securing edges can be done easier - Tragedy of the commons

http://www.ripe.net



Outline




http://www.ripe.net



Securing DNS

• Why to secure DNS? • DNSSEC • Deployment of DNSSEC • Challenges

http://www.ripe.net



The Problem

• DNS data published by the registry is being replaced on its path between the “server” and the “client”.

• This can happen in multiple places in the DNS architecture - Some places are more vulnerable to attacks then others - Vulnerabilities in DNS software make attacks easier

(and there will always be software vulnerabilities)

http://www.ripe.net



DNS Architecture

Registry DB

Primary DNS server

Secondary DNS server

Cache server

Registrars

Client

Cache server

DNS Protocol Provisioning

http://www.ripe.net



DNS Architecture

Registry DB

Server compromise

Registrars

DNS Protocol Provisioning

Inter-server communication

Cache Poisoning

http://www.ripe.net



Solution: DNSSEC

• Sign the data - Each resource record separately

• Secure delegation points - Sign the keys of the children

• Allow building a chain of trust from a Trust Anchor to the actual record

• A Metaphor: - Compare DNSSEC to a sealed transparent envelope

http://www.ripe.net



.net

How DNSSEC works

root

.net

www.ripe.net ?

http://www.ripe.net



ripe.net

.net

How DNSSEC works

root

.net

www.ripe.net ?

http://www.ripe.net



ripe.net

.net

.net =

How DNSSEC works

root root=

.net

www.ripe.net ?

Trust anchor

http://www.ripe.net



ripe.net

ripe.net =

.net

.net =

How DNSSEC works

root root=

.net

ripe.net

www.ripe.net ?

Trust anchor

http://www.ripe.net



www.ripe.net=193.0.19.25

ripe.net

ripe.net =

.net

.net =

How DNSSEC works

root root=

.net

ripe.net

www.ripe.net ?

Trust anchor

http://www.ripe.net



DNSSEC protection

Registry DB

Registrars Registrants

‘envelope sealed’ ‘Seal checked’

‘Seal checked’ DNS Protocol Provisioning

http://www.ripe.net



DNSSEC properties

• DNSSEC secures the name to address mapping - Transport and Application security are just other layers

• DNSSEC provides message authentication and integrity verification through cryptographic signatures - Authentic DNS source - No modifications between signing and validation

• It does not provide authorisation • It does not provide confidentiality

http://www.ripe.net



DNSSEC secondary benefits

• DNSSEC provides an “independent” trust path - The person administering “https” is most probably a

different from person from the one that does “DNSSEC” - The chains of trust are most probably different

http://www.ripe.net



DNSSEC at the RIPE NCC

• Service commitment with the community drawn up in 2005 • DNSSEC operations introduced on 1 January 2006 • Initially, the NCC signed all forward zones

(eg. ripe.net) and reverse /8 zones (eg. 193.in-addr.arpa) ‏• The NCC also began

signing the ENUM (e164.arpa) zone in November 2007

http://www.ripe.net



DNSSEC Setup

signer

provisioning server ns-pri.ripe.net

unsigned zones signed zones

publish signed zones

RIPE database Domain

objects

http://www.ripe.net



Trust anchors

• Because the parent is not signed each /8 is a trust anchor • Trust anchors of all our signed zones are published at

https://www.ripe.net/projects/disi/keys/index.html • BIND-style file which can be easily included • File is signed with the RIPE NCC PGP key

http://www.ripe.net



Secure delegation points

• Users insert their DS (delegated signer) records into parents zones via the RIPE database • Create domain objects with the appropriate DS

attributes

http://www.ripe.net



Operational impact of DNSSEC

• CPU usage on the server doubled - from about 8% to about 16%

• Traffic to the server went up by 60% • There was no noticeable increase in memory usage

http://www.ripe.net



How about the ‘client’ side

• Set up your caching nameserver to perform validation and the infrastructure behind it is protected

• DNSSEC has not yet been pushed to the host or application

• Costs are in maintaining trust anchors - There is no standard to automate against

http://www.ripe.net



Challenges

• New technology; chicken and egg • L9 issues at the top • Zone walking possibility

- Is this really an issue in your environment? - Solutions are there - NSEC3

• Higher security vs increased complexity • Automated key rollover and distribution

http://www.ripe.net



Outline




http://www.ripe.net



Securing Routing

• Why to secure Routing • Certification: A starting point for routing security • Internet resource certification • Challenges

Why to secure routing?

http://www.ripe.net



If I were really bad (and evil)…

I’d attack the routing system • Through routing I’d attack:

- the DNS system - isolate critical public servers and resources - overwhelm the routing system with spurious information - generate a massive routing overload situation to bring

down entire regional routing domains

• And see if I could bring the network to a complete chaotic halt

http://www.ripe.net



What’s the base problem here?

• Routing is built on mutual trust models of varying quality • Routing auditing is a low value but expensive activity • It’s a tragedy of the commons situation:

- Nobody can single-handedly apply rigorous tests on the routing system

- And the lowest common denominator approach is to apply no integrity tests at all

- All trust and no defence

http://www.ripe.net



So we need routing security

like we need clean air and clean water

• But what does this “need” mean? - Who wants to pay for decent security? - What’s the business drivers for effective security? - How do you avoid diversions into security

pantomimes and functionless veneers?

• Can you make decent security and also support “better, faster and cheaper” networked services?

http://www.ripe.net



Threats

• Corrupting the routers’ forwarding tables can result in: - Misdirecting traffic (subversion, denial of service, third

party inspection, passing off) - Dropping traffic (denial of service, compound attacks) - Adding false addresses into the routing system (support

compound attacks) - Isolating or removing the router from the network

http://www.ripe.net



Address and Routing Security

The basic routing payload security questions that need to be answered are:

- Is this a valid address prefix?

- Who injected this address prefix into the network?

- Did they have the necessary credentials to inject this address prefix?

- Is the forwarding path to reach this address prefix an acceptable representation of the network’s forwarding state?

Can these questions be answered reliably, cheaply and quickly?

http://www.ripe.net



A Foundation for Routing Security

• The use of authenticatable attestations to allow automated validation of: - the authenticity of the route object being advertised - authenticity of the origin AS - the binding of the origin AS to the route object

• Such attestations used to provide a cost effective method of validating routing requests - as compared to the today’s state of the art based on

techniques of vague trust and random whois data mining

http://www.ripe.net



• Certification of the “Right-of-Use” of IP Addresses and AS numbers as a linked attribute of the Internet’s number resource allocation and distribution framework

• Adoption of some basic security functions into the Internet’s routing domain: • Injection of reliable trustable data

A Resource PKI as the base of validation of network data

• Explicit verifiable mechanisms for integrity of data distribution Adoption of some form of certified authorization mechanism to

support validation of credentials associated with address and routing information

Certification: A Starting Point for Routing Security

http://www.ripe.net



X.509 Extensions for IP Addresses

• RFC3779 defines extension to the X.509 certificate format for IP addresses & AS number

• The extension binds a list of IP address blocks and AS numbers to the subject of a certificate

• These extensions may be used to convey the issuer’s authorization of the subject for exclusive use of the IP addresses and autonomous system identifiers contained in the certificate extension

• The extension is defined as a critical extension - Validation includes the requirement that the Issuer’s certificate

extension must encompass the resource block described in the extension of the certificated being validated

http://www.ripe.net



What is being Certified For example: RIPE NCC (the “Issuer”) certifies that:

the certificate “Subject” whose public key is contained in the certificate

is the current controller of a set of IP address and AS resources that are listed in the certificate extension

RIPE NCC does NOT certify the identity of the subject, nor their good (or evil) intentions!

Resource Certificates

AFRINIC APNIC ARIN RIPE NCC LACNIC

LIR1 LIR2

ISP ISP ISP ISP ISP ISP ISP

Resource Allocation Hierarchy



LIR LIR

ISP ISP ISP ISP ISP ISP ISP


Issued Certificates match allocation actions



LIR1 LIR2

ISP ISP ISP ISP4 ISP ISP ISP

Issuer: RIPE NCC Subject: LIR2 Resources: 192.2.0.0/16 Key Info: <lir2-key-pub> Signed: <ripencc-key-priv>

Issued Certificates




LIR1 LIR2


Issuer: RIPE NCC Subject: LIR2 Resources: 192.2.0.0/16 Key Info: <lir2-key-pub> Signed: <ripencc-key-priv>

Issued Certificates


Issuer: LIR2 Subject: ISP4 Resources: 192.2.200.0/24 Key Info: <isp4-key-pub> Signed: <lir2-key-priv>



NIR1 NIR2


Issuer: RIPE NCC Subject: LIR2 Resources: 192.2.0.0/16 Key Info: <lir2-key> Signed: <ripencc-key-priv>

Issued Certificates


Issuer: LIR2 Subject: ISP4 Resources: 192.2.200.0/22 Key Info: <isp4-key> Signed: <lir2-key-priv>

Issuer: ISP4 Subject: ISP4-EE Resources: 192.2.200.0/24 Key Info: <isp4-ee-key> Signed: <isp4-key-priv>

http://www.ripe.net



What could you do with Resource Certificates?

• You could sign routing origination authorities or routing requests with your private key, providing an authority for an AS to originate a route for the named prefix. A Relying Party can validate this authority in the RPKI

• You could use the private key to sign routing information in an Internet Route Registry

• You could attach a digital signature to a protocol element in a routing protocol

• You could issue signed derivative certificates for any sub-allocations of resources

Signed Objects


LIR1 LIR2


Issued Certificates


Route Origination Authority “ISP4 permits AS65000 to originate a route for the prefix 192.2.200.0/24”

Attachment: <isp4-ee-cert>

Signed, ISP4 <isp4-ee-key-priv>

Signed Object Validation


LIR1 LIR2


Issued Certificates





1. Did the matching private key sign this text?



LIR1 LIR2


Issued Certificates




Signed, ISP4 <isp4-ee-key-priv> 2. Is this certificate valid?



LIR1 LIR2


Issued Certificates





RIPE NCC Trust Anchor

3. Is there a valid certificate path from a Trust Anchor to this certificate?



LIR1 LIR2


Issued Certificates





RIPE NCC Trust Anchor Validation Outcomes

1. ISP4 authorized this Authority document

2. 192.2.200.0/24 is a valid address, derived from an RIPE NCC allocation

3. ISP4 holds a current right-of-use of 192.2 200.0/24

4. A route object, where AS65000 originates an advertisement for the address prefix 192.2.200.0/24, has the explicit authority of ISP4, who is the current holder of this address prefix

http://www.ripe.net



Intended Objectives • Create underlying framework for route security measures • Assist ISP business process accuracy with Peering and Customer

Configuration tool support • Improve the integrity of published data through the signing and verification

capability in the RIPE Database, IRR and similar

http://www.ripe.net



What this does NOT do

• Compete with sBGP, soBGP, pgBGP, … proposals - It is intended to provide a robust validation framework that

supports the operation of such proposals that intend to secure the operation of the BGP protocol

• Insert another critical point of vulnerability into the Internet - No intention of defining a framework of certificate-enforced

compliance as a precursor to network reachability - Interpretation of validation outcomes is a local policy

preference outcome

http://www.ripe.net



Challenges

• Critical mass of adoption - Even basic route filtering is not a common practice - Little incentive

• More complex provisioning system - Requires modifications and expertise

• A long road to secure routing - RPKI and ROAs only secure origination requests - S*-BGP - more comprehensive proposals, but much more

complex and demanding

http://www.ripe.net



Summary

• Securing the Internet means securing: - The edge - The infrastructure - The between

• Securing DNS and routing is challenging and requires a lot of coordination - Lead by example, share experience - Take responsibility as a community - Make it easier

• But this will make the Internet a better and safer place

http://www.ripe.net


Questions?

Documents

Facilitating Secure Internet Infrastructure · 2008. 4. 23. · A Foundation for Routing Security • The use of authenticatable attestations to allow automated validation of: -