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
The internet keeps connecting directly
4
2012 Source:
https://labs.ripe.net/Members/mirjam/update-on-as-path-lengths-over-time
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
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
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
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
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
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
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
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
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
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
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
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
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
Summary for IXPs
IXP Operators must create RPKI ROAs for their Peering LAN Prefix
IXP Operators must enforce “invalid == reject” on Route Servers