Routing Security Considerations
1 like380 views
- RPKI-based BGP origin validation protects network operators from misconfigurations and route hijacking by other networks by validating that the originating ASN matches the ROA for the prefix. - Direct peering combined with RPKI deployment makes validation stronger by removing dependencies on intermediate transit providers. - For ccTLD operators, deploying RPKI and applying an "invalid route = reject" policy helps secure routing for their DNS prefixes and protects others as well.
Routing Security Considerations
- 1. Routing Security Considerations Job Snijders NTT Communications / AS 2914 job@ntt.net
- 2. What is it we are doing here? ● Making money? ● Sharing a hallucination? ● Facilitation of communication? ● Whatever it is – disruptions cause harm
- 3. Agenda peering considerations, let’s take a DNS server as example Attack scenario walkthrough Recommendations Tools Resources Q & A
- 4. The internet keeps growing 2019, Source: https://bgp.potaroo.net/as6447/
- 5. Also, the internet keeps connecting directly 4 2012 Source: https://labs.ripe.net/Members/mirjam/update-on-as-path-lengths-over-time
- 6. Traditional benefits of peering / BGP anycasting ccTLD operato r Interme diate Provide r AS XXX Google AS 15169 Scenario through transit, AS_PATH is 2 hops: XXX_15169 ccTLD operato r Google AS 15169 Scenario with direct peering: AS_PATH is 1 hop: _15169$ ● No dependency on the intermediate provider (simpler operations) ● Simplified capacity management ● Good latency ● Spreading out DDoS absorption ● Etc etc
- 7. Hijack / misconfiguration scenario ccTLD Operato r Interme diate provide rs Google AS 15169 Attacker AS 15562 Interme diate provide rs Interme diate provide rs 185.25.28.0/24 185.25.28.0/23 Paths from AS ccTLDASN perspective: 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)
- 8. Hijack / misconfiguration scenario – direct peering Google AS 15169 Attacker AS 15562 185.25.28.0/24 185.25.28.0/23 Paths from AS ccTLDASN perspective: 185.25.28.0/23 ccTLDASN_15169 185.25.28.0/24 ccTLDASN_15562 (wins) ccTLD Operato r
- 9. Enter RPKI ROAs 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
- 10. Hijack / misconfiguration scenario – RPKI ROA Google AS 15169 Attacker AS 15562 185.25.28.0/24 185.25.28.0/23 Paths from AS ccTLDASN perspective: 185.25.28.0/23 ccTLDASN_15169 (wins) 185.25.28.0/24 ccTLDASN_15562 (rejected, wrong prefix length) CcTLD operator applying “invalid == reject” ccTLD Operato r
- 11. Change of tactics: announce same prefix Google AS 15169 Attacker AS 15562 185.25.28.0/23 185.25.28.0/23 Paths from AS ccTLDASN perspective: 185.25.28.0/23 ccTLDASN_15169 (wins) 185.25.28.0/23 ccTLDASN_15562 (rejected, wrong Origin ASN) Cloudflare applying “invalid == reject” ccTLD Operato r
- 12. Change of tactics: spoof origin: NOT EFFECTIVE! Google AS 15169 Attacker AS 15562 185.25.28.0/23 185.25.28.0/23 Paths from AS ccTLDASN perspective: 185.25.28.0/23 ccTLDASN_15169 (wins) 185.25.28.0/23 ccTLDASN_15562_15169 (not shortest AS_PATH) Cloudflare applying “invalid == reject” Spoofe d Google AS 15169 ccTLD Operato r
- 13. Summary for ccTLD Operators ● 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 DNS prefixes to help others help you ● Apply “Invalid = Reject” policies on your multi-homed nodes ● Ask your vendors (ISPs and IXPs) to perform Origin Validation ● Direct peering, combined with RPKI, is extremely strong!
- 14. RPKI based traffic analysis with pmacct
- 15. pmacct’s RPKI capabilities ● RFC 6811 Origin Validation procedure is applied ● Mark traffic based on Validation Status, without deploying RPKI in your network ● This helps you understand the effects of rejecting “RPKI invalid” announcements ● Pmacct version 1.7.3
- 16. Most importantly, pmacct recognises the 2 types There are false positives which are: ● Unrecoverable, there is no alternative path ● Implicitly repaired, because there is a covering less-specific valid or unknown route. There are from NTT’s perspective no “Unrecoverable” important destinations, and honestly if we deploy OV, we are doing as they are asking us to do.
- 17. A view from AS 2914 / NTT’s global backbone
- 18. The path towards Origin Validation deployment It is quite simple. DEPLOY. NOW. RPKI based BGP Origin Validation, With “Invalid == reject” routing polices
- 19. Validator situation: very good ● NLNetlabs Routinator (rust, fast,) ● Cloudflare OctoRPKI / GoRTR (go, fast) ● OpenBSD rpki-client(1) (C, in private beta, most basic option) ● Dragon Research Labs RPKI Toolkit (Python + SQL) ● ZDNS’ RPSTIR (C language) ● RIPE NCC RPKI Validator version 3 (java, slowish, lots of features)
- 20. Friends wrote a book, have a look
- 21. NLNetlabs made a website: rpki.readthedocs.io
- 22. RIPE Labs RPKI checker tool https://www.ripe.net/s/rpki-test
- 23. RIPE Labs RPKI checker tool https://www.ripe.net/s/rpki-test
- 25. RPKI Deployment •AT&T rejects invalids on peering sessions •KPN / AS 286 rejects invalids on customer sessions •Nordunet rejects invalids on all EBGP sessions •Seacomm & Workonline drop invalids per April 2019 •INEX, AMS-IX, DE-CIX, France-IX, Netnod, MSK-IX •XS4ALL, Redhosting, BIT, Atom86, Fusix, True, Amsio... •You…. ?
- 26. Question everything! Feel free to ask questions, ask for clarifications If you don’t want to use the microphone, please email me job@ntt.net Network Engineers Without Borders!