securing internet routing bknix2019 · 2019. 5. 7. · •for routing, the address holder can...

1 v1.01

Securing Internet Routing

Tashi Phuntsho (tashi@apnic.net) Senior Network Janitor/Technical Trainer

2 v1.02

Why should we bother?

• As a Managerq I don’t want to be front page news of a IT paper, or an actual

newspaper for routing errors

3 v1.03

Headlines

https://blog.thousandeyes.com/internet-vulnerability-takes-down-google/

4 v1.04

Headlines

https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies

5 v1.05

Headlines

After leak (JP->JP)After leak (EU->EU)

https://dyn.com/blog/large-bgp-leak-by-google-disrupts-internet-in-japan/

6 v1.06

Headlines

7 v1.07

Why should we bother?

• As a Engineerq I don’t want to be told at 3AM my routing is brokenq Or while on a holiday

8 v1.08

Why do we keep seeing these?

• Because NO ONE is in charge?q No single authority model for the Internetq No reference point for what’s right in routing

9 v1.09

Why do we keep seeing these?

• Routing works by RUMOURq Tell what you know to your neighbors, and Learn what your

neighbors knowq Assume everyone is correct (and honest)

§ Is the originating network the rightful owner?

10 v1.010

Why do we keep seeing these?

• Routing is VARIABLEq The view of the network depends on where you are

§ Different routing outcomes at different locations

q ~ no reference view to compare the local view L

11 v1.011

Why do we keep seeing these?

• Routing works in REVERSEq Outbound advertisement affects inbound trafficq Inbound (Accepted) advertisement influence outbound traffic

12 v1.012

Why do we keep seeing these?

• And as always, there is no E-bit q A bad routing update does not identify itself as BAD

• So tools/techniques try to identify GOOD updates

13 v1.013

Why should we worry?

• Because it’s just so easy to do bad in routing!

By Source (WP:NFCC#4), Fair use, https://en.wikipedia.org/w/index.php?curid=42515224

14 v1.014

Current practice

Peering/Transit Request

LOA Check

Filters (in/out)

15 v1.015

Tools & Techniques

LOA Check

Whois(manual)

Letter of Authority IRR (RPSL)

16 v1.016

Tools & Techniques

• Look up whoisq verify holder of

a resource

17 v1.017

Tools & Techniques

• Ask for a Letter of Authorityq Absolve from any liabilities

18 v1.018

Tools & Techniques

• Look up/ask to enter details in internet routing registries (IRR)q describes route origination and

inter-AS routing policies

19 v1.019

Tools & Techniques

• IRRq Helps auto generate network

(prefix/as-path) filters using RPSL tools§ Filter out route advertisements not

described in the registry

20 v1.020

Tools & Techniques

• Problem(s) with IRRq No single authority model

§ How do I know if a RR entry is genuine and correct?§ How do I differentiate between a current and a lapsed entry?

q Many RRs§ If two RRs contain conflicting data, which one do I trust and use?

q Incomplete data - Not all resources are registered in an IRR§ If a route is not in a RR, is the route invalid or is the RR just missing data?

q Scaling§ How do I apply IRR filters to upstream(s)?

21 v1.021

Back to basics – identifying GOOD

• Using digital signatures to convey the “authority to use”? q A private key to sign the authority, andq the public key to validate that authority

22 v1.022

How about trust in this framework?

• Follows the resource allocation/delegation hierarchy

IANA à RIRs à NIRs/LIRs à End Holders|V

End Holders

23 v1.023

RPKI Chain of Trust

IANA

RIPE-NCCLACNICARIN APNICAFRINIC

NIR

ISP ISP ISP ISP

Allocation Hierarchy

Trust Anchor Certificate

Certificate chain

mirrors the allocation hierarchy

Cert (CA)

Cert (EE)

Cert (EE)

Cert (EE)

Cert (EE)

Cert (CA)

Cert (CA)

Image 4

24 v1.024

Resource Certificates

• When an address holder A (*IRs) allocates resources (IP address/ASN) to B (end holders)

q A issues a resource certificate that binds the allocated address with B’s public key, all signed by A’s (CA) private key

q proves the holder of the private key (B) is the legitimate holder of the resource!

25 v1.025

Route Origin Authorization (ROA)

• B can now sign authorities using its private key, which can be validated by any third party against the TA

• For routing, the address holder can authorize a network (ASN) to originate a route, and sign this permission with its private key (ROA)

Prefix 203.176.32.0/19

Max-length /24

Origin ASN AS17821

26 v1.026

Route Origin Validation (ROV)

RPKI-to-Router (RtR)

rsync/RRDP

RPKI Validator/RPKI Cache server

2406:6400::/32-48

17821

.1/:1

.2/:2

AS17821

ASXXXX

Global (RPKI)

Repository

ROA

2406:6400::/32-48

17821

TATA

TA

2406:6400::/48

27 v1.027

Are ROAs enough?

• What if I forge the origin AS in the AS path?q Would be accepted as “good” – pass origin validation!

• Which means, we need to secure the AS path as wellq Need AS path validation (per-prefix)

28 v1.028

AS path validation - BGPsec

AS1 AS2

AS3

AS4

AS1 -> AS2(Signed AS1)

AS1 -> AS2(Signed AS1)

AS2->AS3(signed AS2)

AS1 -> AS2(Signed AS1)

AS2->AS4(signed AS2)

q A BGPsec speaker validates the received update by checking:§ If there is a ROA that describes the prefix and origin AS§ If the received AS path can be validated as a chain of signatures (for each AS

in the AS path) using the AS keys

29 v1.029

AS path validation issues…

• More resourcesq CPU - high crypto overhead to validate signatures, andq Memory

§ Updates in BGPsec would be per prefix§ New attributes carrying signatures and certs/key-id for every AS in the AS

path

• How do we distribute the certificates required?

• Can we have partial adoption?

• Given so much overhead, can it do more - Route leaks?

30 v1.030

What can we do?

• Basic BGP OpSec hygiene – RFC7454/RFC8212

q RFC 8212 – BGP default reject or something similar

q Filters with your customers and peers § Prefix filters, Prefix limit § AS-PATH filters, AS-PATH limit § Use IRR objects (source option) or ROA-to-IRR

q Filters with your upstream(s)

q Create ROAs for your resources§ Filter based on ROAs -> ROV

• Join industry initiatives like MANRS§ https://www.manrs.org/

31 v1.031

ROV – Industry trends

MMIX is dropping Invalids!

32 v1.032

Acknowledgement

5280

• Geoff Huston, APNIC• Randy Bush, IIJ Labs/Arrcus

33 v1.033

Any questions?