How-to – Implement RPKI in 3 simple steps

What’s RPKI?

Although sounding complicated, Resource Public Key Infrastructure is just a way to secure the internet against IPv4/v6 prefix hijacks and leaks. To achieve that, RPKI will serve your router the trusted information so it can check if eBGP learned prefixes are originating from where they are allowed to (first AS in path) and in the format they are allowed to (subnetmask or subnetmask range). It’s first described in RFC6480.

An ROA (Route Origin Authorization) is kind of a signed IRR and basically has following structure:

ASN |  IPv4/v6 Prefix  |  Mask  | (Optional)  Max. Mask  | signature

These are usually stored on specific servers managed by your responsible IRR org.

2-way implementation

There are 2 independent aspects when you implement RPKI:

• generate ROAs to protect your prefixes. This is usually made on your RIR platform who will act like a “Certification Authority” for it’s managed prefixes.
• implement RPKI Validation to protect your routing-table. Setup your own Validator server who will download and verify the ROAs from the RIRs. A RTR Server (RPKI-to-Router protocol) is needed to send the ROA lists to your  routers.

You can run RPKI on your routers and take routing decisions based on it without having ROAs. You can also create ROAs for your prefixes without having RPKI implemented in your routing logic or network. Implement both is best.

While the title may refer to a very simple and quick process to implement RPKI, you might want to plan this carefully and study the impact on your routing. Best is to go trough the whole process with a /24 that isn’t used for prod.

Here you can see the Cloudflare RPKI diagram neatly describing the whole setup:

Source: https://blog.cloudflare.com/rpki/

Before we start

Well, yes, deploying it could be relatively quick & easy in a small AS but  make sure you take time to fully understand the implications before taking any productive steps. Read through the tutorial and make your own opinion about how you will benefit from it and what risks it involves for your network.

How-to – Simple automated blackholing – Part 5

Upstream/RTBH blackholing

RFC 7999

A simple way to achieve blackholing is when your upstreams support RFC 7999 so you can tag a /32 eBGP announcement with community 666, the upstreams router picks it up and blackholes the prefix on their own network. That is a very simple solution, especially if you have only Tier1 Upstreams and no other eBGP/external Routing like peering IX’s etc.

How-to – Simple automated blackholing – Part 7

Troubleshooting

You might want FNM to send syslogs to understand and keep a record of what’s happening:

$ sudo fcli set main logging_remote_syslog_logging enable
$ sudo fcli set main logging_remote_syslog_port 514
$ sudo fcli set main logging_remote_syslog_server 192.168.10.8
$ sudo fcli commit

To print the whole configuration:

$ sudo fcli show main

To test the API connection & credentials:

$ curl -X GET -u admin:PASSWORD http://127.0.0.1:10007/license

To check if the server gets sFlow packets:

$ sudo tcpdump -i ens160 'port 6343'

To check which ports/services are listening:

$ sudo netstat -tulpen

How-to – Simple automated blackholing – Part 1

Blackholing

An important feature that comes in very handy on every ISP backbone is the ability to backhole incoming traffic to a certain destination in order to prevent it from reaching it’s destination, ideally preventing it from going through your network at all and as I will show you as a bonus, without entering your own network at all. Sounds cool, right?

In our case blackholing means interfering locally on a router by changing it’s next hop to null0 (=discards the packet). It might be something that has been done manually in the past on exceptional events… but nowadays, volumetric attacks are not a rare thing and pick up traffic so fast, we wouldn’t have time to react fast enough: by the time you’d understand which IP is gathering a lot of incoming traffic, it has probably done already a lot of damage. Hence to react fast enough, you might want an automated blackholing process, or at least one you can easily trigger and which would automatically deploy all accross your network.

Two answers

A simple way to get it done is:

• let your upstreams blackhole traffic before reaching your AS, also known as RTBH, so traffic doesn’t even congest your uplinks, as presented in Step 4. (when your upstreams support RFC 7999 so you can tag an /32 eBGP announcement with community 666)
• to blackhole the traffic on your own routers, as presented in Step 5.

They can be both combined for 100% efficiency.

How-to – Simple automated blackholing – Part 2

Fastnetmon Adv.

A very efficient tool written by very talented people: https://fastnetmon.com/product-overview/

Installation

We used a Ubuntu 16.04 as base OS at the time.  Later versions should work too in the meantime.

On the website, you can request a trial license which will activate FNM Adv. for 1 month. There is a relatively small monthly fee to pay for an FNM Advanced license once you’d opt for it, especially given the amount of flexibility the tools grants.

How-to – Simple automated blackholing – Part 4

BGP setup

GoBGP Configuration

Configure FNM to setup GoBGP and add a BGP peering session with a Router or Route-Reflector of yours:

$ sudo fcli set main gobgp enable
$ sudo fcli set main gobgp_announce_host enable
$ sudo fcli set main gobgp_community_host 65002:666
$ sudo fcli set bgp connection_to_r1
$ sudo fcli set bgp connection_to_r1 local_asn 65501
$ sudo fcli set bgp connection_to_r1 remote_asn 65502
$ sudo fcli set bgp connection_to_r1 local_address 192.168.10.10
$ sudo fcli set bgp connection_to_r1 remote_address 10.10.10.255
$ sudo fcli set bgp connection_to_r1 multihop enable
$ sudo fcli set bgp connection_to_r1 ipv4_unicast enable
$ sudo fcli set bgp connection_to_r1 active enable
$ sudo fcli commit

Important :  Not all BGP networks work the same depending on architecture, implementations or route propagation policies. You might want to give this some thought before starting to implement the sample configuration in order to evaluate consequences and potential risks.

How-to – Simple automated blackholing – Part 3

FNM-GUI

Installation

I won’t give a full detailed install guide here, instead follow the probably evolving installation details here:

https://github.com/ukfast/fnm-webui

How-to – Simple network automation with Ansible – Part 1

Worth the effort?

Every now and then you may run into networks that run different brands of devices or same brands but with huge OS version discrepancies. That’s were implementation in any form of network automation becomes complicated. So while you think about using a tool like Ansible you also know you may be limited by time or by complication to get the job done: KISS beeing a reasonable thought in every aspect of IT nobody will blame you for going the custom script way. After all, why build a full automation setup to execute a single task, if there are no other planned configs to deploy in any other use case? Well, let me explain why it might be worth it after all.

It’s here

If you are running a network of a certain size, there is a big chance that you have a certain need for automation. There might be just a single use case for now or even none at all (or so you might think) but chances are high you will need it to keep up with all the automation going on all the services running on top of it, if it’s not already the case.