Improving BGP routing security Job Job S Snijders NTT / / AS AS - - PowerPoint PPT Presentation

▶
improving bgp routing security
SMART_READER_LITE
LIVE PREVIEW

Improving BGP routing security Job Job S Snijders NTT / / AS AS - - PowerPoint PPT Presentation

Nov 28, 2022 455 likes •909 views

Improving BGP routing security Job Job S Snijders NTT / / AS AS 2 2914 job ob@ntt.net http tps:// //tw twitter.com/ om/Job JobSnijders Why are we doing any of this routing security? Creating EBGP routing filters based on

slide-1
SLIDE 1

Improving BGP routing security

Job Job S Snijders NTT / / AS AS 2 2914 job

  • b@ntt.net

http tps:// //tw twitter.com/

  • m/Job

JobSnijders

slide-2
SLIDE 2

2

Why are we doing any of this “routing security”?

  • Creating EBGP routing filters based on public data, forces

malicious actors to leave a trail in IRR, WHOIS or other data sources: auditability

  • Bugs happen! – your router may suddenly ignore parts of your

configuration, you’ll then rely on your EBGP peer’s filters

  • Everyone makes mistakes – a typo is easily made!
slide-3
SLIDE 3

3

Alright – everybody aboard?

slide-4
SLIDE 4

4

IRR vs RPKI – they look alike… right?!

slide-5
SLIDE 5

5

A RPKI ROA in the wild for 2001:67c:208c::/48

Origin ASN …. Prefix……...

slide-6
SLIDE 6

6

A photo of an IRR route6 object

job@vurt ~$ whois -h whois.ripe.net -- '-T route6 2001:67c:208c::/48' | grep -v %

route6: 2001:67c:208c::/48 descr: NL-SNIJDERS-IT

  • rigin: AS15562

mnt-by: SNIJDERS-MNT created: 2015-08-31T14:16:27Z last-modified: 2015-08-31T14:16:27Z source: RIPE

…. Prefix ………..… Origin ASN

slide-7
SLIDE 7

7

IRR vs RPKI – Tomato tomato? Or is it...

slide-8
SLIDE 8

8

The gist of it, IRR vs RPKI:

IRR route object:

  • An IRR route object only say something about the object itself, but not about other existence /

absence of other routing information

  • Route objects are not necessarily created by the resource holder
  • Doesn’t tell us anything about BGP UPDATEs that don’t match the IRR object
  • Unsuitable for filtering your upstream providers

RPKI ROAs:

  • RPKI is the first publication database available through all five RIRs
  • ROAs are created by the resource holder, by definition
  • RPKI ROAs are statements that supersede any other sources of routing information (LOAs, IRR

route objects, emails)

  • RFC 6811 is the game changer – “BGP Origin Validation” requires RPKI as input
  • ROAs can be used on any type of EBGP session (transit/peering/customers) for filters!!!!
slide-9
SLIDE 9

9

OK – peering… where does that come into play ?

A photo of the Internet http://as2914.net/

slide-10
SLIDE 10

10

Isn’t RPKI Origin validation useless without BGPSEC?

Isn’t RPKI Origin validation useless without…. path validation?

slide-11
SLIDE 11

11

Traditionally understood benefits of peering

ccTLD

  • perator

Intermediate Provider AS XXX Google AS 15169 Scenario through transit, AS_PATH is 2 hops: XXX_15169 ccTLD

  • perator

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
slide-12
SLIDE 12

12

The internet keeps growing

2019, Source: https://bgp.potaroo.net/as6447/

slide-13
SLIDE 13

13

Also, the internet keeps connecting directly

4 2012 Source: https://labs.ripe.net/Members/mirjam/update-on-as-path-lengths-over-time

slide-14
SLIDE 14

14

Hijack / misconfiguration scenario

Operator Intermediate providers Google AS 15169 Attacker AS 15562 Intermediate providers Intermediate providers 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)

slide-15
SLIDE 15

15

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) Operator

slide-16
SLIDE 16

16

Enter… a RPKI ROA

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

slide-17
SLIDE 17

17

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)

  • perator applying “invalid == reject”

Operator

slide-18
SLIDE 18

18

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) Operator applying “invalid == reject” Operator

slide-19
SLIDE 19

19

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) Operator applying “invalid == reject” Spoofed Google AS 15169 Operator

slide-20
SLIDE 20

20

Summary for Network Operators like you and me

  • 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 prefixes to help others help you
  • Apply “Invalid = Reject” policies on your routers
  • Ask your vendors (both ISPs and IXPs) to perform Origin Validation

Direct peering, combined with RPKI, is extremely strong!!11oneleven!

slide-21
SLIDE 21

21

The path towards Origin Validation deployment

It is quite simple.

  • DEPLOY. NOW.

RPKI based BGP Origin Validation, With “Invalid == reject” routing polices

slide-22
SLIDE 22

22

RIPE Labs RPKI checker tool

https://ripe.net/s/rpki-test

slide-23
SLIDE 23

23

RIPE Labs RPKI checker tool

https://ripe.net/s/rpki-test

slide-24
SLIDE 24

24

Industry trends

  • Who is doing this?
  • RIPE’s 2018-06 policy
  • IRRd 4 developments
slide-25
SLIDE 25

Deployment update

  • YYCIX
  • Cloudfmare
  • AMS-IX
  • Telia Carrier
  • DE-CIX
  • Tata India
  • KPN
  • Workonline
  • Seacomm
  • AT&T
  • RIPE meetjngs
  • AMSIO
  • BIT
  • Coloclue
  • Telenor
  • FCIX
  • Atom86
  • Noris Network
  • Fusix Networks
  • XS4ALL
  • IETF meetjngs
  • INX
  • NAP Africa
  • Netnod
  • France-IX
  • INEX
  • Nordunet
  • Many others...
slide-26
SLIDE 26

RIPE NWI-5 proposal & implementation: RIPE vs RIPE-NONAUTH

  • RIPE NCC’s IRR previously allowed anyone to register any

non-RIPE-managed space if it had not yet been

  • registered. *THIS IS DANGEROUS*

Steps taken:

  • Cannot register non-RIPE-managed space any more
  • All non-RIPE space moved to separate “RIPE-NONAUTH”

database

More info: htups://www.ripe.net/manage-ips-and-asns/db/impact-analysis-for-nwi-5-implementatjon

slide-27
SLIDE 27

27

Applying Origin Validation to the IRR

  • RPKI ROAs can be used for BGP Origin Validation
  • But, what about applying the RFC 6811 “Origin Validation

Procedure” to IRR data?

  • Perhaps, we should consider unvalidated IRR data objects as if

they are BGP announcements!

slide-28
SLIDE 28

28

RIPE 2018-06 policy: Using RPKI to clean up the IRR

slide-29
SLIDE 29

29

Applying Origin Validation to the IRR

  • RPKI ROAs can be used for BGP Origin Validation
  • But, what about applying the RFC 6811 “Origin Validation

Procedure” to IRR data?

  • Perhaps, we should consider unvalidated IRR data objects as if

they are BGP announcements!

slide-30
SLIDE 30

30

An example

route: 129.250.15.0/24

  • rigin: AS60068

descr: AS60068 route object descr: this is a test of hijack possibilities with current state of RIPE/RADB security setup - this records covers IP address used for rr.ntt.net service descr: please note this is just a demonstrative object, with no real harmful intention mnt-by: DATACAMP-MNT created: 2018-02-10T16:57:07Z last-modified: 2018-09-04T19:07:32Z source: RIPE-NONAUTH

slide-31
SLIDE 31

31

The previous slide is in conflict with this ROA!

$ whois -h whois.bgpmon.net 129.250.15.0/24 % This is the BGPmon.net whois Service % You can use this whois gateway to retrieve information % about an IP adress or prefix % We support both IPv4 and IPv6 address. % % For more information visit: % https://portal.bgpmon.net/bgpmonapi.php Prefix: 129.250.0.0/16 Prefix description: NTT Communications backbone Country code: US Origin AS: 2914 Origin AS Name: NTT-COMMUNICATIONS-2914 - NTT America, Inc., US RPKI status: ROA validation successful First seen: 2019-02-23 Last seen: 2019-05-22 Seen by #peers: 71

slide-32
SLIDE 32

32

RIPE-NONAUTH IRR cleanup “2018-06”

Formal proposal: Apply the Origin Validation procedure to IRR objects in the RIPE- NONAUTH IRR database. The PDP applies here. This proposal remove wrong LACNIC, APNIC, ARIN, AFRINIC route registrations from RIPE-NONAUTH – If and only if there are RPKI ROAs covering the space Implications:

  • proposal does not apply to RIPE-managed space or legacy space
  • There is no efgect if you cannot (or will not) create RPKI ROAs for your space

→ THIS PROPOSAL MAY AFFECT AFRICAN IP SPACE IN RIPE-NONAUTH!!!!!!! <<--

slide-33
SLIDE 33

33

RIPE-NONAUTH IRR cleanup

Changes between version 1.0 and 2.0:

  • Introduced a 7 day hold period
  • Notifications should be send to the IRR route object holder (if

RIPE NCC can).

htups://www.ripe.net/partjcipate/policies/proposals/2018-06 Test tool: htups://github.com/job/ripe-proposal-2018-06

slide-34
SLIDE 34

34

Analyser tool example for AS 7018

$ ripe-proposal-2018-06 -a 7018 Downloading https://rpki.gin.ntt.net/api/export.json Downloading https://ftp.ripe.net/ripe/dbase/split/ripe-nonauth.db.route.gz INVALID! The 99.122.224.0/21AS1273 RIPE-NONAUTH route object has conflicts: route: 99.122.224.0/21 descr: route for customer Akamai International

  • rigin: AS1273

created: 2008-09-08T14:40:49Z last-modified: 2018-09-04T15:54:45Z source: RIPE-NONAUTH mnt-by: CW-EUROPE-GSOC Above non-authoritative IRR object is in conflict with this ROA: ROA: 99.112.0.0/12, MaxLength: 12, Origin AS7018 (ARIN)

slide-35
SLIDE 35

35

Going forward

  • Create RPKI ROAs using the AFRINIC portal!
  • Use the AFRINIC IRR for your route objects!
  • Deploy Origin Validation with “invalid == reject”

On my todo list:

  • Get RADB to import RPKI ROAs as if they are IRR
  • Get Workonline to treat RPKI ROAs like IRR

https://blog.apnic.net/2018/08/01/treating-rpki-roas-as-irr-route6-objects/

slide-36
SLIDE 36
slide-37
SLIDE 37

37

Another efgort: IRRd version 4!

https://github.com/irrdnet/irrd4

slide-38
SLIDE 38

38

Another efgort: IRRd version 4!

  • IRRd version 3 (“Legacy IRRd”) is an organically grown, 20 year
  • ld code base, mostly in C, perl, inefgective database backend
  • Reliability issues with Legacy IRRd
  • Absolutely critical to NTT’s daily operations, all NTT’s prefix-

filters are generated with this sofuware Funded by NTT / AS 2914, developed by Dashcare

slide-39
SLIDE 39

39

Quick overview of the size of the legacy codebase

job@vurt irrd$ cloc . 189 text files. 185 unique files. 28 files ignored. github.com/AlDanial/cloc v 1.74 T=2.25 s (71.9 files/s, 36938.2 lines/s)

  • Language files blank comment code
  • C 92 6645 9205 33967

Perl 10 812 877 12451 Bourne Shell 4 993 1308 9687 C/C++ Header 35 722 549 3608 yacc 1 326 111 1453 make 20 168 63 313

  • SUM: 162 9666 12113 61479

I R R d v e r s i

  • n

4 J u s t ~ 1 , l i n e s

  • f

p y t h

  • n
slide-40
SLIDE 40

40

Benefits of IRRd version 4

  • Single modern architecture with extension options
  • Code base is well documented, consistent, maintainable
  • Extensive regression & integration testing
  • QA checks compared to rr.ntt.net to ensure smooth

transition

  • BSD 2-Clause License

IRRd 4.1 will do Origin Validation on IRR objects (like 2018-06)

slide-41
SLIDE 41

Improving security at the aggregator

AFRINIC NTTCOM RADB APNIC … whois.radb.net rr.ntu.net bgpq3

Data sources Aggregators Clients

slide-42
SLIDE 42

RPKI fjlter at the aggregators (IRRd 4.1)

AFRINIC NTTCOM RADB APNIC … whois.radb.net rr.ntu.net bgpq3

Data sources Aggregators Clients

slide-43
SLIDE 43

43

Using the RPKI to clean up conflicting IRR

  • Industry-wide common method to get rid of stale proxy route
  • bjects – by creating a ROA you hide old garbage in IRRs
  • By creating a ROA – you will significantly decrease the chances
  • f people being able to use IRR to hijack your resource
slide-44
SLIDE 44

44

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 (I am happy to help competitors too) Network Engineers Without Borders!