Share
Like
Double tap to zoom out
Improving the peering business case with RPKI Slide 1 Improving the peering business case with RPKI Slide 2 Improving the peering business case with RPKI Slide 3 Improving the peering business case with RPKI Slide 4 Improving the peering business case with RPKI Slide 5 Improving the peering business case with RPKI Slide 6 Improving the peering business case with RPKI Slide 7 Improving the peering business case with RPKI Slide 8 Improving the peering business case with RPKI Slide 9 Improving the peering business case with RPKI Slide 10 Improving the peering business case with RPKI Slide 11 Improving the peering business case with RPKI Slide 12 Improving the peering business case with RPKI Slide 13 Improving the peering business case with RPKI Slide 14 Improving the peering business case with RPKI Slide 15 Improving the peering business case with RPKI Slide 16 Improving the peering business case with RPKI Slide 17 Improving the peering business case with RPKI Slide 18 Improving the peering business case with RPKI Slide 19 Improving the peering business case with RPKI Slide 20
Share
Like
1 / 20

Improving the peering business case with RPKI

427
views

APNIC

1,659 uploads
Presentation by Job Snijders at APRICOT 2019 on Tuesday, 26 February 2019.
Published in: Internet
Recommended

Improving the peering business case with RPKI

  1. 1. Improving the peering business case with RPKI Job Snijders NTT Communications job@ntt.net
  2. 2. 2 Agenda ● Traditional benefits of peering ● RPKI considerations for IP network operators ● RPKI considerations for IXP operators
  3. 3. 3 Traditional benefits of peering Cloudflare AS 13335 Intermediate Provider AS XXX Google AS 15169 Scenario through transit, AS_PATH is 2 hops: XXX_15169 Cloudflare AS 13335 Google AS 15169 Scenario with direct peering: AS_PATH is 1 hop: _15169$ ● No dependency on the intermediate provider (simpler operations) ● Reduced cost (cross-connect often is cheaper than using an intermediate network if you are in the same building) ● Simplified capacity management ● Etc etc
  4. 4. 4 The internet keeps connecting directly 4 2012 Source: https://labs.ripe.net/Members/mirjam/update-on-as-path-lengths-over-time
  5. 5. 5 Hijack / misconfiguration scenario Cloudflare AS 13335 Intermediate providers Google AS 15169 Attacker AS 15562 Intermediate providersIntermediate providers 185.25.28.0/24 185.25.28.0/23 Paths from AS 13335 perspective: 185.25.28.0/23 13335_XXX_15169 185.25.28.0/23 13335_YYY_15169 185.25.28.0/24 13335_ZZZ_15562 (wins)
  6. 6. 6 Hijack / misconfiguration scenario – direct peering Cloudflare AS 13335 Google AS 15169 Attacker AS 15562 185.25.28.0/24 185.25.28.0/23 Paths from AS 13335 perspective: 185.25.28.0/23 13335_15169 185.25.28.0/24 13335_15562 (wins)
  7. 7. 7 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
  8. 8. 8 Hijack / misconfiguration scenario – RPKI ROA Cloudflare AS 13335 Google AS 15169 Attacker AS 15562 185.25.28.0/24 185.25.28.0/23 Paths from AS 13335 perspective: 185.25.28.0/23 13335_15169 (wins) 185.25.28.0/24 13335_15562 (rejected, wrong prefix length) Cloudflare applying “invalid == reject”
  9. 9. 9 Change of tactics: announce same prefix Cloudflare AS 13335 Google AS 15169 Attacker AS 15562 185.25.28.0/23 185.25.28.0/23 Paths from AS 13335 perspective: 185.25.28.0/23 13335_15169 (wins) 185.25.28.0/23 13335_15562 (rejected, wrong Origin ASN) Cloudflare applying “invalid == reject”
  10. 10. 10 Change of tactics: spoof origin – NOT EFFECTIVE! Cloudflare AS 13335 Google AS 15169 Attacker AS 15562 185.25.28.0/23 185.25.28.0/23 Paths from AS 13335 perspective: 185.25.28.0/23 13335_15169 (wins) 185.25.28.0/23 13335_15562_15169 (not shortest AS_PATH) Cloudflare applying “invalid == reject” Spoofed Google AS 15169
  11. 11. 11 Summary for Network Operators ● RPKI based BGP Origin Validation protects against misconfigurations ● Origin Validation blocks out more-specifics (malicious or not) ● Shortest AS_PATH is now a security feature ● Direct peering, combined with RPKI, is extremely strong!
  12. 12. 12 Considerations for IXP operators Every IXP has a vulnerable spot: the Peering LAN Prefix Imagine DE-CIX Frankfurt – 80.81.192.0/21 Imagine I announce 80.81.192.0/24 to the Default-Free Zone If IX participants accept a more-specific of the Peering LAN Prefix, BGP packets may go the wrong place. Some BGP implementations follow the RIB/FIB for BGP packets → result – BGP sessions across IXP go down. BAD
  13. 13. 13 IXP Operator problem space Asking everyone to filter out the Peering LAN prefix is problematic: ● what if you grow the IXP peering lan? Email everyone? ● what about stale configurations, if people don’t update? ● there are 1000+ IXPs world-wide, will all of them email everyone?
  14. 14. 14 IXP Operator recommendation ● Create RPKI ROAs for your Peering LAN Prefixes! ● Set MaxLength to exactly the same as the prefix length ● Use Origin “AS 0” or the IXP Services ASN ● Don’t announce the Peering LAN Prefix
  15. 15. 15 IXP Route Server considerations Source: BKNIX https://bknix.co.th
  16. 16. 16 IXP Route Server Considerations Route Server intention is to mimick direct peering, and provide a convenience service to participants. But if you have an ASN, you have a responsibility. Applies to IXPs too! When networks create RPKI ROAs, we expect them to be honored... Customers expect excellent leadership from IXP Operators!
  17. 17. 17 IXP Route Server Considerations We discussed the benefits of RPKI and direct peering. Therefore, IXP Route Server must deploy “RPKI Invalid == Reject” policies! No reason not to, all modern Route Server software supports RPKI: ● IXP Manager ● Arouteserver ● BIRD ● OpenBGPD
  18. 18. 18 IXPs using RPKI based Origin Validation ● YYCIX ● INEX ● AMS-IX ● FranceIX ● DE-CIX (soon!) ● Netnod (soon!) ● Others? ● …. you? More information: http://peering.exposed/
  19. 19. 19 Summary for IXPs IXP Operators must create RPKI ROAs for their Peering LAN Prefix IXP Operators must enforce “invalid == reject” on Route Servers
  20. 20. 20 Questions? Ask at the microphone! Or email me at job@ntt.net

×