- 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.

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

24. Deployment update
•Cloudflare
•YYCIX

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!