Trusted CI Webinar Series

Today’s webinar topic is "Deployable Internet Routing Security" with Amir

Herzberg.

Our host is Jeannette Dopheide.

The meeting will begin shortly. Participants are muted. Click the Chat button to

open the chat view and ask a question.

This meeting will be recorded.

The Trusted CI Webinar Series is supported by National Science Foundation grant #1547272.

The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the NSF.

Deployable Internet Routing Security

AmirHerzbergUniversityofConnecticut

ComputerScienceandEngineering©

666

• Background: internet routing (in)security• ROV and RPKI to the rescue ? • Deployment challenges, impact• Our efforts to improve RPKI (and its deployment)• Background: (DNS) amplification DDoS attacks• uRPF to the rescue ? • Our efforts to improve, deploy uRPF• Summary

Deployable Internet Routing Security

• Focus: inter-AS (auth-system, domain) routing• Inter-AS Routing is notoriously vulnerable

• Misrouting: incorrect destination• To attacker (hijack) or blackhole/victim (DoS)• Even short-lived is significant, e.g., DNS poisoning

• Spoof: incorrect source• Goals: clogging (amplification-based DoS), DNS-poison

• ‘Daily’ problems, attacks (DoS, spam/phishing, …)

• Attempts to fix from the 1990s • Standards (RPKI, BGPsec): (almost) not deployed

• Research goal: deployable effective defenses

Internet Routing (in)Security

Misrouting:Real-LifeExample

MitM,DNSpoisoning

Denialofservice

Spam/phishing

Malwaredistribution

AttackGoals:

TrafficAnalysis

- Manyproposed/deployeddefenses,overmanyyears…- Challenge&focus:deployable yeteffective defenses

Eavesdropping

BGPAnnouncement:IPprefix– ASpath

Avoidloops:ifASalreadyonpath,ignoreannouncement

AS 100

AS 300

AS 200180.10.0.0/16

BGP Announcements, Policy

PathPrefix180.10.0.0/16 100

PathPrefix180.10.0.0/16 200_100

PathPrefix180.10.0.0/16 300_100

AS 400

PathPrefix180.10.0.0/16 400_300_100

BGPpolicyforeachprefix:- Whatannouncement

touse?- Whatannouncement

toannounce?towhom?Relationships:provider,customer,peer

AS 500

AS 100

AS 300

AS 200180.10.0.0/16

Valley-Free BGP Policy

PathPrefix180.10.0.0/16 100

PathPrefix180.10.0.0/16 200_100

PathPrefix180.10.0.0/16 300_100

AS 400

PathPrefix180.10.0.0/16 400_300_100

Foreachprefix….Usebestannouncement:1st preference:customer2nd preference:viapeer3rd preference:providerSamerelationship?

Useshorterpath!Announce? If to/from customer

PrefixHijack(1):betterrelationship[prefercustomersoverpeersandpeersoverproviders]

7BGP

announcementData flow

to 91.0.0.0/10Inter-AS

link….

AS 11AS 33

AS 666

91.0.0.0/10Path: 33

91.0.0.0/10Path: 666

AS 1

PrefixHijack(1):prefershorterroute

1

22

333

666

1.2.0.0/16Path: 333

1.2.0.0/16Path: 22-333

1.2.0.0/16Path: 666

8BGP

announcementData flow

to 1.2.0.0/16Inter-domain

link….

Randomly placed attacker, ‘victim AS’ èequal prob for attacker vs. legit origin…

If prefix is announced at all!

PrefixHijack(3):Hijackunannouncedprefix!

9BGP

announcementData flow

to 91.0.0.0/10Inter-AS

link….

AS 1

AS 666

91.0.0.0/10Path: 666

(useforspam,phishing,DoS,…)

Sub-prefixHijack(3):Sameasunannouncedprefix!

10BGP

announcementData flow

to 91.0.0.0/10Inter-AS

link….

AS 1

AS 33

AS 66691.0.0.0/10

Path: 33

91.0.0.0/16Path: 666

More specific rule: traffic flows toward most specific prefix

Rare Occurrence?12/6/15

Dec. 9, 2014: Syrian Telco (AS29386) makes hundreds of BGP announcements for prefixes it does not own/operate

AS4847 – “China Networks“ announces 136.38.33.0/24, which is in /11 assigned to AS16591 (google)” [message on Nanog, 4/6/19]

• Background: internet routing (in)security• ROV and RPKI to the rescue ? • Deployment challenges, impact• Our efforts to improve RPKI (and its

deployment)• Background: (DNS) amplification DDoS attacks• uRPF to the rescue ? • Our efforts to improve, deploy uRPF• Summary

DeployableInternetRoutingSecurity

RouteOriginValidation(ROV):prevent(sub)prefix-hijacks

1

22

333

1.2.0.0/16Route: 22-333

1.2.0.0/16Route: 666

BGP Ann. Data flow

Domain 1 uses the (longer but correct) route 22-333, since only domain 333 is authorized origin for prefix 1.2.0.0/16 13

Route Origin Validation (ROV)

How??

666

How to do RouteOriginValidation(ROV)

??Manually: keep a list of valid (authorized)origin ASes for each prefix

Online check: consult DBs, e.g., Internet Routing Registries (IRRs)[unreliable!]

Offline, reliable: RPKI - digitally-signedRoute Origin Authorization (ROA)

RPKI:ResourcePublicKeyInfrastructure• RFC6480: resource (prefix) owner gets Resource Certificate (RC)• Assigning prefix: super-prefix owner (or RIR – Regional Internet

Registry) signs Resource Certificates (RC): {prefix,v.owner}s.RIR

• Prefix-owner signs Route Origin Authorization (ROA): {prefix,AS.origin}s.owner

• Only signed-origin may announce prefix 1.2/16• Announcement of sub-prefixes requires valid ROA !

• For simplicity, ignore signing details: assume no forgeries

ROA: Prefix: 1.2/16Origin: 333

RPKI:ResourcePublicKeyInfrastructure• Owner signs Route Origin Authorization (ROA): {prefix,AS.origin}s.owner

• For simplicity, ignore signing details: assume no forgeries• Also ignored: max-length option• Convention: Origin = AS 0 è no origin

• Facilitates Route Origin Validation (ROV) by BGP (border) Routers: • Drop BGP announcements of prefixes within 1.2/16• Where Origin AS is not 333• Unless allowed by another (valid) ROA…• è prevents prefix & subprefix hijacks (false origin domain)

ROA: Prefix: 1.2/16Origin: 333

RouteOriginValidation(ROV)preventsPrefix,Sub-PrefixHijacks

1

22

333

1.2.0.0/16Route: 22-333

1.2.0.0/16Route: 666

BGP Ann. Data flow

Domain 1 uses the (longer but correct) route 22-333, since only domain 333 is authorized origin for prefix

1.2.0.0/16 (and no sub-prefixes w/o ROA)

17

ROA: 1.2.0.0/16Origin 333

Route Origin Validation (ROV)

666

• Background: internet routing (in)security• ROV and RPKI to the rescue ? • Deployment challenges, impact• Our efforts to improve RPKI (and its deployment)• Background: (DNS) amplification DDoS attacks• uRPF to the rescue ? • Our efforts to improve, deploy uRPF• Summary

Deployable Internet Routing Security

RPKI Adoption ChallengesRequires both authorizations (RCsàROAs) and

validation (ROV)Risk: `False’ Announcement-ROA conflict

ROA forbids legitimate BGP announcement(s)Typical, real-life example:

RIPE

Orange(Francetelecom)194.2.0.0/15

194.2.35.0/24AS1272(Danone)

194.2.0.0/15AS3215

ResourceCertificateROA

194.2.155.0/24AS8361(Ubisoft)

194.3.118.0/24AS34444(Eutelsat)

InvalidBGPAnnouncement

Legend:

Must Orange issue ROA only after all customers issued ??

RPKI Adoption ChallengesRequires both authorizations (RCs, ROAs) and validation (ROV)

Risk: (many!) `False’ announcement-ROA conflict- ROA changes from default-allow to default-deny

- No ROA over prefix: any BGP announcement is Ok - ROV validation returns `unknown’ (can’t validate)

- ROA over prefix: only announcements allowed by ROA- ROV returns either `valid’ or `invalid’…

- No noticeable impact… until ROV is widely applied- How common are announcement-ROA conflicts?

- Vs. `good’ (no conflict) ROAs…

BGP Announcements vs. ROAs: HistoryAnnouncements without ROA:702,079 (86.4%)

With valid ROAs:104,402 (12.85%)

With invalid ROAs:6,117 (0.75%)

~6% of announcements conflict with ROAs!!… slow improvement… too slow?

Dropping ‘invalid’ announcements may cause loss of traffic…

How many ISPs apply ROV (drop invalid)?

Measurements of ROV deployment

DSN’18Can’t directly measureThree methods:

Infer from RouteViewannouncements

Trace-route to RIPE-Atlas probes

Trace-route to TCP`reflectors’

è Disappointing !Only 0.03% possibly protectedLater improvement, e.g.,

AT&T [Feb’19]Why so few deploy ROV?

Why isn’t ROV (more) deployed?

§ Deploying ROV: even harder than other standards§ Transit ASes get paid for Traffic, connectivity§ What’s impact of adopting ROV ? § More traffic? better security attracts customers§ Less traffic? Filtering (ROV) drops announcements

§ Less traffic, less customers ? § Surely bad: dropping legitimate BGP announcements

§ What’s the impact of partial ROV deployment?

Security with Partial ROV Adoption

Subprefix hijack

success rate

Comparison between two scenarios:today’s status, as reflected by our measurements all top 100 ISPs perform Route Origin Validation (ROV)

Each other AS does ROV with fixed probability

RouteOriginValidation(ROV)bythetopASesisnecessary andsufficient

forsubstantialsecuritybenefitsfromRPKI

Whypartialadoptionissoineffective?Collateraldamage!• Domains not doing ROV might cause ROV-enforcing

domains to fall victim to subprefix hijacking• Control-Plane vs. Data-Plane Mismatch: domain

discards invalid announcement, yet data flows to attacker

1

2

666

3

To: 1.1.0.0/16route: 2_1

To: 1.1.1.0/24route: 666

Domain 2 advertises only valid route (valley-free) Domain 3 enforces ROV

Domain 2 uses invalid route for subprefix è traffic to 1.1.1.0/24 still hijacked! 27

ROA: 1.1.0.0/16Origin 1

• Background: internet routing (in)security• ROV and RPKI to the rescue ? • Deployment challenges, impact• Our RPKI/ROV efforts• Background: (DNS) amplification DDoS attacks• uRPF to the rescue ? • Our efforts to improve, deploy uRPF• Summary

DeployableInternetRoutingSecurity

Our RPKI/ROV efforts• With community: Education, peer-pressure, publicity, ….

• The ROV Forecast web-service: https://sidr.engr.uconn.edu• Estimate impact of deploying ROV by any given AS

• Based on extrapolation of Internet-wide BGP paths from collector data• Measure accuracy against real hijacks• Compare different ROV variants/policies

• Improved (?) ROV variants:• Avoid false positives: automated-whitelist: allow ‘invalid but long-lived’

announcements• ROV++ : avoid collaborative damage• Path-end: prevent origin hijack [hidden foils; SigComm’16]

• Experimental deployment: UConn + CEN• ROV, ROAs• And routing-based defenses against DoS

BW-DoS: DNS Open ResolversMillions of DNS Open Resolvers…

Huge (bandwidth): OpenDNS, Google Pub-DNS…Millions (unprotected): home routers, etc…

Allow attacker to control responseI.e., send max length (4096B) responsesResponse is cached – negligible `cost’ of sending

Victim

DNSResolver

ns.666.org

Requests: all for TXT x.666.org,

Spoofed srcIP of victim

request

responses

AS222

AS666Open

Resolver

AS44

2.2.2.0/23

BW-DoS: DNS Open Resolvers§ DNS Open Resolver – known problem:

§ Most unmanaged: home routers, campus§ Few managed, large: OpenDNS, …

§ Small spoofed requests§ Long responses§ Victim congested

§ uRPF ?

Requests, src=2.2.2.2

Responses, Dst=2.2.2.2

AS222

AS666Open

Resolver

AS44

2.2.2.0/23

unicast Reverse-Path Filtering (uRPF)q Drop incoming packet if..

q Strict: not received from path to srcq Feasible: no path to src from interfaceq Loose: no path to src

q Why not strict? Risk of false positive(not this example)

q Attacker can foil byprefix hijack

q RPKI can help…q To prevent hijacksq To prevent false-positives

Requests, src=2.2.2.2

Responses, Dst=2.2.2.2

• Internet routing is vulnerable, attacked• Misrouting (for interception, spam, phishing, DoS, …)• Spoofing (mainly for amplification DDoS)

• RPKI/ROV may help• Against misrouting, spoofing, amplification DDoS• Extensions may improve security, ease deployment

• Deployment: a challenge – but feasible ! • SIDR monitor and other resources:

https://sidr.engr.uconn.edu

Summary: Deployable Internet Routing Security

Questions?Please take our survey

2019 Cybersecurity Technology Transition to Practice (TTP) workshop - June 19th, ChicagoFor more info and to request an invitation, go to our TTP page: https://trustedci.org/ttp

Trusted CI at PEARC19July 28 - August 1, Chicago

https://www.pearc19.pearc.org/

Save the Date: NSF Cybersecurity Summit Oct. 15 - 17 in San Diego

https://trustedci.org/summit

About the Trusted CI Webinar series

To view presentations, join the announcements mailing list, or submit requests

to present, visit: https://trustedci.org/webinars

The next webinar is June 24th at 11am Eastern.

Topic: The Trusted CI Framework: An Architecture for Cybersecurity Programs

Speakers: Craig Jackson, Kay Avila, and Bob Cowles

trustedci.org