Improving BGP routing security Job Job S Snijders NTT / / AS AS 2 2914 job ob@ntt.net http tps:// //tw twitter.com/ om/Job JobSnijders
Why are we doing any of this “routing security”? • Creating EBGP routing filters based on public data, forces malicious actors to leave a trail in IRR, WHOIS or other data sources: auditability • Bugs happen ! – your router may suddenly ignore parts of your configuration, you’ll then rely on your EBGP peer’s filters • Everyone makes mistakes – a typo is easily made! 2
Alright – everybody aboard? 3
IRR vs RPKI – they look alike… right?! 4
A RPKI ROA in the wild for 2001:67c:208c::/48 Origin ASN …. Prefix……... 5
A photo of an IRR route6 object job@vurt ~$ whois -h whois.ripe.net -- '-T route6 2001:67c:208c::/48' | grep -v % …. Prefix route6: 2001:67c:208c::/48 descr: NL-SNIJDERS-IT ………..… Origin ASN origin: AS15562 mnt-by: SNIJDERS-MNT created: 2015-08-31T14:16:27Z last-modified: 2015-08-31T14:16:27Z source: RIPE 6
IRR vs RPKI – Tomato tomato? Or is it... 7
The gist of it, IRR vs RPKI: IRR route object: ● An IRR route object only say something about the object itself, but not about other existence / absence of other routing information ● Route objects are not necessarily created by the resource holder ● Doesn’t tell us anything about BGP UPDATEs that don’t match the IRR object ● Unsuitable for filtering your upstream providers RPKI ROAs: ● RPKI is the first publication database available through all five RIRs ● ROAs are created by the resource holder, by definition ● RPKI ROAs are statements that supersede any other sources of routing information (LOAs, IRR route objects, emails) ● RFC 6811 is the game changer – “BGP Origin Validation” requires RPKI as input ● ROAs can be used on any type of EBGP session (transit/peering/customers) for filters!!!! 8
OK – peering… where does that come into play ? A photo of the Internet http://as2914.net/ 9
Isn’t RPKI Origin validation useless without BGPSEC? Isn’t RPKI Origin validation useless without…. path validation? 10
Traditionally understood benefits of peering Scenario through transit, AS_PATH is 2 hops: XXX_15169 Intermediate ccTLD Google Provider operator AS 15169 AS XXX Scenario with direct peering: AS_PATH is 1 hop: _15169$ ● No dependency on the intermediate provider (simpler operations) ● Simplified capacity management ccTLD Google ● Good latency operator AS 15169 ● Spreading out DDoS absorption ● Etc etc 11
The internet keeps growing 2019, Source: https://bgp.potaroo.net/as6447/ 12
Also, the internet keeps connecting directly 4 2012 Source: https://labs.ripe.net/Members/mirjam/update-on-as-path-lengths-over-time 13
Hijack / misconfiguration scenario 185.25.28.0/23 Intermediate Google Operator Intermediate providers AS 15169 providers Intermediate providers 185.25.28.0/24 Attacker Paths from AS ccTLDASN perspective: AS 15562 185.25.28.0/23 ccTLDASN_XXX_15169 185.25.28.0/23 ccTLDASN_YYY_15169 185.25.28.0/24 ccTLDASN_ZZZ_15562 (wins) 14
Hijack / misconfiguration scenario – direct peering 185.25.28.0/23 Google Operator AS 15169 185.25.28.0/24 Attacker Paths from AS ccTLDASN perspective: AS 15562 185.25.28.0/23 ccTLDASN_15169 185.25.28.0/24 ccTLDASN_15562 (wins) 15
Enter… a RPKI ROA Prefix: 185.25.28.0/23 Prefix description: Google Country code: CH Origin AS: 15169 Origin AS Name: GOOGLE - Google LLC, US RPKI status: ROA validation successful MaxLength: 23 First seen: 2016-01-08 Last seen: 2019-02-26 Seen by #peers: 40 16
Hijack / misconfiguration scenario – RPKI ROA operator applying “invalid == reject” 185.25.28.0/ 23 Google Operator AS 15169 185.25.28.0/ 24 Attacker Paths from AS ccTLDASN perspective: AS 15562 185.25.28.0/23 ccTLDASN_15169 (wins) 185.25.28.0/24 ccTLDASN_15562 (rejected, wrong prefix length) 17
Change of tactics: announce same prefix Operator applying “invalid == reject” 185.25.28.0/ 23 Google Operator AS 15169 185.25.28.0/ 23 Attacker Paths from AS ccTLDASN perspective: AS 15562 185.25.28.0/23 ccTLDASN_15169 (wins) 185.25.28.0/23 ccTLDASN_15562 (rejected, wrong Origin ASN) 18
Change of tactics: spoof origin: NOT EFFECTIVE! Operator applying “invalid == reject” 185.25.28.0/ 23 Google Operator AS 15169 Attacker AS 15562 185.25.28.0/ 23 Paths from AS ccTLDASN perspective: 185.25.28.0/23 ccTLDASN_15169 (wins) Spoofed Google 185.25.28.0/23 ccTLDASN_15562_15169 (not shortest AS_PATH) AS 15169 19
Summary for Network Operators like you and me ● RPKI based BGP Origin Validation protects you against other people’s misconfigurations, Origin Validation blocks out more- specifics (whether malicious or not). ● Shortest AS_PATH is now a security feature: keep peering ● Create ROAs for your own prefixes to help others help you ● Apply “Invalid = Reject” policies on your routers ● Ask your vendors (both ISPs and IXPs) to perform Origin Validation Direct peering, combined with RPKI, is extremely strong!!11oneleven! 20
The path towards Origin Validation deployment It is quite simple. DEPLOY. NOW. RPKI based BGP Origin Validation, With “Invalid == reject” routing polices 21
RIPE Labs RPKI checker tool https://ripe.net/s/rpki-test 22
RIPE Labs RPKI checker tool https://ripe.net/s/rpki-test 23
Industry trends ● Who is doing this? ● RIPE’s 2018-06 policy ● IRRd 4 developments 24
Deployment update • YYCIX • AMSIO • Cloudfmare • BIT • AMS-IX • Coloclue • Telia Carrier • Telenor • DE-CIX • FCIX • Tata India • Atom86 • NAP Africa • KPN • Noris Network • Netnod • Workonline • Fusix Networks • France-IX • Seacomm • XS4ALL • INEX • AT&T • IETF meetjngs • Nordunet • RIPE meetjngs • INX • Many others...
RIPE NWI-5 proposal & implementation: RIPE vs RIPE-NONAUTH • RIPE NCC’s IRR previously allowed anyone to register any non-RIPE-managed space if it had not yet been registered. *THIS IS DANGEROUS* Steps taken: • Cannot register non-RIPE-managed space any more • All non-RIPE space moved to separate “RIPE-NONAUTH” database More info: htups://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementatjon
Applying Origin Validation to the IRR ● RPKI ROAs can be used for BGP Origin Validation ● But, what about applying the RFC 6811 “Origin Validation Procedure” to IRR data? ● Perhaps, we should consider unvalidated IRR data objects as if they are BGP announcements! 27
RIPE 2018-06 policy: Using RPKI to clean up the IRR 28
Applying Origin Validation to the IRR ● RPKI ROAs can be used for BGP Origin Validation ● But, what about applying the RFC 6811 “Origin Validation Procedure” to IRR data? ● Perhaps, we should consider unvalidated IRR data objects as if they are BGP announcements! 29
An example route: 129.250.15.0/24 origin: AS60068 descr: AS60068 route object descr: this is a test of hijack possibilities with current state of RIPE/RADB security setup - this records covers IP address used for rr.ntt.net service descr: please note this is just a demonstrative object, with no real harmful intention mnt-by: DATACAMP-MNT created: 2018-02-10T16:57:07Z last-modified: 2018-09-04T19:07:32Z source: RIPE-NONAUTH 30
The previous slide is in conflict with this ROA! $ whois -h whois.bgpmon.net 129.250.15.0/24 % This is the BGPmon.net whois Service % You can use this whois gateway to retrieve information % about an IP adress or prefix % We support both IPv4 and IPv6 address. % % For more information visit: % https://portal.bgpmon.net/bgpmonapi.php Prefix: 129.250.0.0/16 Prefix description: NTT Communications backbone Country code: US Origin AS: 2914 Origin AS Name: NTT-COMMUNICATIONS-2914 - NTT America, Inc., US RPKI status: ROA validation successful First seen: 2019-02-23 Last seen: 2019-05-22 Seen by #peers: 71 31
RIPE-NONAUTH IRR cleanup “2018-06” Formal proposal: Apply the Origin Validation procedure to IRR objects in the RIPE- NONAUTH IRR database. The PDP applies here. This proposal remove wrong LACNIC, APNIC, ARIN, AFRINIC route registrations from RIPE-NONAUTH – If and only if there are RPKI ROAs covering the space Implications: - proposal does not apply to RIPE-managed space or legacy space - There is no efgect if you cannot (or will not) create RPKI ROAs for your space → THIS PROPOSAL MAY AFFECT AFRICAN IP SPACE IN RIPE-NONAUTH!!!!!!! <<-- 32
RIPE-NONAUTH IRR cleanup Changes between version 1.0 and 2.0: ● Introduced a 7 day hold period ● Notifications should be send to the IRR route object holder (if RIPE NCC can). htups://www.ripe.net/partjcipate/policies/proposals/2018-06 Test tool: htups://github.com/job/ripe-proposal-2018-06 33
Recommend
More recommend
