Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

Routing Security Considerations

180 visualizaciones

Publicado el

Presentació a càrrec de Job Snijders, arquitecte d'internet a NTT Communications duta a terme prèviament a la 40a reunió de la Comissió Tècnica del CATNIX el 28 de juny de 2019.

Publicado en: Tecnología
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Routing Security Considerations

  1. 1. Routing Security Considerations Job Snijders NTT Communications / AS 2914
  2. 2. What is it we are doing here? ● Making money? ● Sharing a hallucination? ● Facilitation of communication? ● Whatever it is – disruptions cause harm
  3. 3. Agenda peering considerations, let’s take a DNS server as example Attack scenario walkthrough Recommendations Tools Resources Q & A
  4. 4. The internet keeps growing 2019, Source:
  5. 5. Also, the internet keeps connecting directly 4 2012 Source:
  6. 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. 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 Paths from AS ccTLDASN perspective: ccTLDASN_XXX_15169 ccTLDASN_YYY_15169 ccTLDASN_ZZZ_15562 (wins)
  8. 8. Hijack / misconfiguration scenario – direct peering Google AS 15169 Attacker AS 15562 Paths from AS ccTLDASN perspective: ccTLDASN_15169 ccTLDASN_15562 (wins) ccTLD Operato r
  9. 9. Enter RPKI ROAs Prefix: 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. 10. Hijack / misconfiguration scenario – RPKI ROA Google AS 15169 Attacker AS 15562 Paths from AS ccTLDASN perspective: ccTLDASN_15169 (wins) ccTLDASN_15562 (rejected, wrong prefix length) CcTLD operator applying “invalid == reject” ccTLD Operato r
  11. 11. Change of tactics: announce same prefix Google AS 15169 Attacker AS 15562 Paths from AS ccTLDASN perspective: ccTLDASN_15169 (wins) ccTLDASN_15562 (rejected, wrong Origin ASN) Cloudflare applying “invalid == reject” ccTLD Operato r
  12. 12. Change of tactics: spoof origin: NOT EFFECTIVE! Google AS 15169 Attacker AS 15562 Paths from AS ccTLDASN perspective: ccTLDASN_15169 (wins) ccTLDASN_15562_15169 (not shortest AS_PATH) Cloudflare applying “invalid == reject” Spoofe d Google AS 15169 ccTLD Operato r
  13. 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. 14. RPKI based traffic analysis with pmacct
  15. 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. 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. 17. A view from AS 2914 / NTT’s global backbone
  18. 18. The path towards Origin Validation deployment It is quite simple. DEPLOY. NOW. RPKI based BGP Origin Validation, With “Invalid == reject” routing polices
  19. 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. 20. Friends wrote a book, have a look
  21. 21. NLNetlabs made a website:
  22. 22. RIPE Labs RPKI checker tool
  23. 23. RIPE Labs RPKI checker tool
  24. 24. Deployment update •Cloudflare •YYCIX
  25. 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. 26. Question everything! Feel free to ask questions, ask for clarifications If you don’t want to use the microphone, please email me Network Engineers Without Borders!