Post on 25-Feb-2022
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