Skip to content

Commit

Permalink
update rpki details for ubuntu 20.04 - closes #16
Browse files Browse the repository at this point in the history
  • Loading branch information
@barryo
barryo committed Sep 18, 2020
1 parent 1497691 commit 2c4ff29
Show file tree
Hide file tree
Showing 9 changed files with 224 additions and 372 deletions.
20 changes: 11 additions & 9 deletions docs/features/rpki.md
View file
Expand Up @@ -47,37 +47,39 @@ Start by installing two local caches / validator services as linked above. INEX

Once your maintenance window starts, stop the target route server you plan to upgrade. You'll then need to to remove the Bird v1 package (`dpkg -r bird` on Ubuntu). Once the Bird package is removed, you can perform a distribution upgrade if you wish.

At time of writing (May 2019), there are no Bird v2 packages for Debian or Ubuntu. As such, you need to install from source. Rather than installing a build environment and compiling on each server, you can do this on a single server (a dedicated build box / admin server / etc) and then distribute the package across your route servers / collector:
Bird v2 is available as a prebuilt package with Ubuntu 20.04 LTS and can be installed with `apt install bird2`.

There are no Bird v2 packages for Ubuntu 18.04 LTS. As such, you need to install from source if using that older platform. Rather than installing a build environment and compiling on each server, you can do this on a single server (a dedicated build box / admin server / etc) and then distribute the package across your route servers / collector:

```sh
# Install Ubuntu build packages and libraries Bird requires:
apt install -y build-essential libssh-dev libreadline-dev \
libncurses-dev flex bison checkinstall

# At time of writing, the latest release was v2.0.6.
# At time of writing, the latest release was v2.0.7.
# Check for newer versions!
cd /usr/src
wget ftp://bird.network.cz/pub/bird/bird-2.0.6.tar.gz
tar zxf bird-2.0.6.tar.gz
cd bird-2.0.6/
wget ftp://bird.network.cz/pub/bird/bird-2.0.7.tar.gz
tar zxf bird-2.0.7.tar.gz
cd bird-2.0.7/
./configure --prefix=/usr --sysconfdir=/etc
make -j2
checkinstall -y
```

The `checkinstall` tool creates a deb package file: `/usr/local/src/bird-2.0.6/bird_2.0.6-1_amd64.deb`
The `checkinstall` tool creates a deb package file: `/usr/local/src/bird-2.0.7/bird_2.0.7-1_amd64.deb`

**NB: for this method to work, you must be running the same operating system and version on the target servers as the build box.** For us, it was Ubuntu 18.04 LTS on all systems.

To install on a target machine:

```sh
# from build machine
scp bird_2.0.6-1_amd64.deb target-machine:/tmp
scp bird_2.0.7-1_amd64.deb target-machine:/tmp

# on target machine
apt install -y libssh-dev libreadline-dev libncurses-dev
dpkg -i /tmp/bird_2.0.6-1_amd64.deb
dpkg -i /tmp/bird_2.0.7-1_amd64.deb
```

You now need to update your route server record in IXP Manager:
Expand All @@ -86,7 +88,7 @@ You now need to update your route server record in IXP Manager:
* check *Enable RPKI filtering*;
* update the template to `api/v4/router/server/bird2/standard`.

Note that the Bird v2 template uses large BGP communities extensively internally. The option *Enable Large BGP Communities / RFC8092* only controls whether your members can use large communities for filtering. *It's 2019 - you should really enable this.*
Note that the Bird v2 template uses large BGP communities extensively internally. The option *Enable Large BGP Communities / RFC8092* only controls whether your members can use large communities for filtering. *It's 2020 - you should really enable this.*

As mentioned above, you need to let IXP Manager know where your local caching / validators are by setting the following `.env` settings:

Expand Down
142 changes: 35 additions & 107 deletions docs/features/rpki/cloudflare.md
View file
Expand Up @@ -3,157 +3,85 @@

Cloudflare created their own RPKI toolkit which, similar to RIPE's, is split into two elements:

1. **GoRTR** is the damon that implements the RPKI-RTR protocol to distribute validated ROAs to your routers.
1. **GoRTR** is the daemon that implements the RPKI-RTR protocol to distribute validated ROAs to your routers.
2. **OctoRPKI** is the validator which pulls the signed ROAs from the trust anchors and validates them and then makes them available to GoRTR.

**NB:** Before you proceed further, you should [read Cloudflare's own introduction to this toolkit](https://blog.cloudflare.com/cloudflares-rpki-toolkit/).

We use a standard Ubuntu 18.04 installation (selecting the minimal virtual server option), 2 vCPUs, 2GB RAM, 10GB LVM hard drive. Not that INEX at this point has not embraced Docker for production services so our install does not use Cloudflare's docker options.
We use a standard Ubuntu 20.04 installation (selecting the minimal virtual server option), 2 vCPUs, 2GB RAM, 20GB LVM hard drive.

Rather than running these daemons as the root user, we create a dedicated user:
Cloudflare provide pre-built packages for installation - visit the following URLs and download the appropriate packages for your operating system:

```sh
useradd -c 'cloudflare' -d /srv/cloudflare -m -s /bin/bash -u 1102 cloudflare
```
* https://github.com/cloudflare/cfrpki/releases
* https://github.com/cloudflare/gortr/releases

We now install packages we need:
In my case, with Ubuntu 20.04 in September 2020, I ended up installing the following:

```sh
apt install golang git rsync ca-certificates
wget https://github.com/cloudflare/cfrpki/releases/download/v1.1.4/octorpki_1.1.4_amd64.deb
wget https://github.com/cloudflare/gortr/releases/download/v0.14.6/gortr_0.14.6_amd64.deb
dpkg -i gortr_0.14.6_amd64.deb octorpki_1.1.4_amd64.deb
```

Note that in the following, we are not signing the JSON file or ROAs that OctoRPKI generates and this not validating this in GoRTR. The reason for this as primarily that it *just wouldn't work* (May 2019) but also as this is a same server operation and no other tools are using the JSON.

## OctoRPKI

To install OctoRPKI, su to the target user and proceed as follows (we assume all commands are executed from `/srv/cloudflare`):

```sh
sudo su - cloudflare

go get github.com/cloudflare/cfrpki/cmd/octorpki

# test:
./go/bin/octorpki -h

# create the directories we need:
mkdir tals && mkdir cache && touch rrdp.json

# copy files we need from the OctoRPKI repository:
cp go/src/github.com/cloudflare/cfrpki/cmd/octorpki/tals/* tals/
```

You now need to install the ARIN file manually, sigh:

1. Visiting https://www.arin.net/resources/rpki/tal.html
2. Downloading the TAL in RFC 7730 format
3. Place it in `/srv/cloudflare/tals/arin.tal`
3. Place it in `/usr/share/tals/arin.tal`


You can now run the validator via the following command *(and I'm showing the start of some of the sample output)*:
You can now run the validator via the following command *(and I'm also showing how to see the log)*:

```sh
$ ./go/bin/octorpki -mode server -output.sign=0
INFO[0000] Validator started
INFO[0000] Serving HTTP on :8080/output.json
...
```

As it starts up, there is some info available as JSON under http://localhost:8080/infos and the ROAs can be seen as JSON via http://localhost:8080/output.json after ~5mins.



## GoRTR
# start the service:
systemctl start octorpki

To install GoRTR (once OctoRPKI is installed and running), we proceed as follows and assume you are su'd to `cloudflare` and your current directory is `/srv/cloudflare`:
# see and tail the logs
journalctl -fu octorpki

```sh
go get github.com/cloudflare/gortr/cmd/gortr
# enable to start on server boot:
systemctl enable octorpki.service
```

You can run it now with:
At the time of writing with the above mentioned versions, we have the following error in the

```sh
./go/bin/gortr -bind :3323 \
-verify=0 \
-cache http://localhost:8080/output.json \
-metrics.addr :8081
```

Once GoRTR starts up, metrics are available from http://127.0.0.1:8081/metrics.

## Starting on Boot

To have these services start at boot, we create systemd service files:


```sh
cat <<ENDL >/etc/systemd/system/cloudflare-octorpki.service
[Unit]
Description=Cloudflare OctoRPKI Validator
[Service]
Restart=always
RestartSec=60
WorkingDirectory=/srv/cloudflare
User=cloudflare
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=cloudflare-octorpki
ExecStart=/srv/cloudflare/go/bin/octorpki -mode server -output.sign=0
[Install]
WantedBy=multi-user.target
ENDL
Error adding Resource tals/arin.tal: illegal base64 data at input byte 4
```

```sh
cat <<ENDL >/etc/systemd/system/cloudflare-gortr.service
[Unit]
Description=Cloudflare GoRTR
After=cloudflare-octorpki.service
This is referenced in the follow [GitHub issue for octorpki #53](https://github.com/cloudflare/cfrpki/issues/53) and is solved by editing `/usr/share/tals/arin.tal` and removing the line starting `https://...` and then restart (`systemctl restart octorpki`).

[Service]
Restart=always
RestartSec=60
As it starts up, there is some info available as JSON under `http://[hostname/ip address]:8080/infos` and the ROAs can be seen as JSON via `http://[hostname/ip address]:8080/output.json` after ~5mins.

WorkingDirectory=/srv/cloudflare

User=cloudflare
## GoRTR

StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=cloudflare-gortr
To start GoRTR (once OctoRPKI is configured and running), we first edit `/etc/default/gortr`:

ExecStartPre=/bin/sleep 30
```
GORTR_ARGS=-bind :3323 -verify=false -cache http://localhost:8080/output.json -metrics.addr :8081
```

ExecStart=/srv/cloudflare/go/bin/gortr -bind :3323 -verify=0 -cache http://localhost:8080/output.json -metrics.addr :8081 -refresh=120
You can now run the GoRTR daemon via the following command *(and I'm also showing how to see the log)*:

```sh
# start the service:
systemctl start gortr

[Install]
WantedBy=multi-user.target
# see and tail the logs
journalctl -fu gortr

ENDL
# enable to start on server boot:
systemctl enable gortr.service
```

And then we enable for start on boot with:

```sh
systemctl enable cloudflare-octorpki.service
systemctl enable cloudflare-gortr.service
```
Once GoRTR starts up, metrics are available from http://[hostname/ip address]:8081/metrics.

Note that:

* we have a sleep on gortr of 30 seconds to give OctoRPKI a chance to start;
* even still, it may not be ready in which case gortr will retry every two minutes (`-refresh=120`).

## Monitoring

Expand Down
62 changes: 30 additions & 32 deletions docs/features/rpki/routinator.md
View file
@@ -1,9 +1,9 @@

# Routinator 3000

**Routinator 3000** is a [RPKI](/features/rpki.md) relying party software (aka RPKI Validator) written in Rust by the good folks at [NLnet Labs](https://www.nlnetlabs.nl/projects/rpki/routinator/). These instructions reflect Routinator 0.4, which is set up and started differently than older versions. This mostly follows [their own GitHub instructions](https://github.com/NLnetLabs/routinator) and [documentation](https://rpki.readthedocs.io/en/latest/routinator/).
**Routinator 3000** is a [RPKI](/features/rpki.md) relying party software (aka RPKI Validator) written in Rust by the good folks at [NLnet Labs](https://www.nlnetlabs.nl/projects/rpki/routinator/). These instructions reflect Routinator 0.7.1 (on Ubuntu 20.04). This mostly follows [their own GitHub instructions](https://github.com/NLnetLabs/routinator) and [documentation](https://rpki.readthedocs.io/en/latest/routinator/).

We use a standard Ubuntu 18.04 installation (selecting the minimal virtual server option), 2 vCPUs, 2GB RAM, 10GB LVM hard drive.
We use a standard Ubuntu 20.04 installation (selecting the minimal virtual server option), 2 vCPUs, 2GB RAM, 20GB LVM hard drive.

Rather than running Routinator as the root user, we create a dedicated user:

Expand All @@ -17,21 +17,22 @@ We then install the required software. `build-essential` is a Ubuntu alias packa
apt install -y build-essential cargo rsync
```

You should have rust version >=1.36.0 installed (check with `rustc -V`).
You should have rust version >=1.43.0 installed (check with `rustc -V`).

To install Routinator, we then switch to the `routinator` user and use Cargo to build and install it:

```sh
sudo su - routinator
cargo install routinator
cargo install --locked routinator
```

To check if this works, run the following (and note the path to the `routinator` binary):

```sh
routinator@rpki01:~$ /srv/routinator/.cargo/bin/routinator -V
Routinator 0.6.1
Routinator 0.7.1
```

Routinator needs to prepare its working environment via the `init` command, which will set up both
the directory for the local RPKI cache as well as the TAL directory. Running it will prompt you to
agree to the [ARIN Relying Party Agreement (RPA)](https://www.arin.net/resources/manage/rpki/tal/)
Expand All @@ -57,7 +58,7 @@ and increases the log level to show the process in detail at least once):
To upgrade Routinator, you reinstall it (`-f` to overwrite the older version):

```sh
cargo install -f routinator
cargo install --locked --force routinator
```

After you upgrade, kill the running version of Routinator and start it again.
Expand All @@ -80,7 +81,9 @@ When it starts, there is a webserver on port 8080 - see [the documentation for t

## Starting on Boot

To have this service start at boot, we create systemd service files:
To have this service start at boot, we create systemd service files.

**Edit this to reflect your correct IP address(es).**


```sh
Expand Down Expand Up @@ -126,52 +129,47 @@ The following is copied [from Routinator's man page](https://nlnetlabs.nl/docume

```
HTTP SERVICE
Routinator can provide an HTTP service allowing to fetch the Validated
ROA Payload in various formats. The service does not support HTTPS and
Routinator can provide an HTTP service allowing to fetch the Validated
ROA Payload in various formats. The service does not support HTTPS and
should only be used within the local network.
The service only supports GET requests with the following paths:
/csv Returns the current set of VRPs in csv output format.
/json Returns the current set of VRPs in json output format.
/metrics
Returns a set of monitoring metrics in the format used by
Returns a set of monitoring metrics in the format used by
Prometheus.
/openbgpd
Returns the current set of VRPs in openbgpd output format.
/rpsl Returns the current set of VRPs in rpsl output format.
/status
Returns the current status of the Routinator instance. This is
similar to the output of the /metrics endpoint but in a more
Returns the current status of the Routinator instance. This is
similar to the output of the /metrics endpoint but in a more
human friendly format.
/version
Returns the version of the Routinator instance.
/api/v1/validity/as-number/prefix
Returns a JSON object describing whether the route announcement
given by its origin AS number and address preifx is RPKI valid,
invalid, or not found. The returned object is compatible with
that provided by the RIPE NCC RPKI Validator. For more informa-
tion, see https://www.ripe.net/support/documentation/developer-
Returns a JSON object describing whether the route announcement
given by its origin AS number and address prefix is RPKI valid,
invalid, or not found. The returned object is compatible with
that provided by the RIPE NCC RPKI Validator. For more informa-
tion, see https://www.ripe.net/support/documentation/developer-
documentation/rpki-validator-api
/validity?asn=as-number&prefix;=prefix
/validity?asn=as-number&prefix=prefix
Same as above but with a more form-friendly calling convention.
The paths that output the current set of VRPs accept filter expressions
to limit the VRPs returned in the form of a query string. The field
filter-asn can be used to filter for ASNs and the field filter-prefix
can be used to filter for prefixes. The fields can be repeated multiple
times.
In addition, the current set of VRPs is available for each output for-
mat at a path with the same name as the output format. E.g., the CSV
output is available at /csv.
These paths accept filter expressions to limit the VRPs returned in the
form of a query string. The field filter-asn can be used to filter for
ASNs and the field filter-prefix can be used to filter for prefixes.
The fields can be repeated multiple times.
This works in the same way as the options of the same name to the vrps
command.
```
2 changes: 1 addition & 1 deletion site/features/layer2-addresses/index.html
View file
Expand Up @@ -1643,7 +1643,7 @@ <h2 id="end-user-access">End User Access<a class="headerlink" href="#end-user-ac
<div class="md-source-date">
<small>

Last update: <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">August 20, 2020</span>
Last update: <span class="git-revision-date-localized-plugin git-revision-date-localized-plugin-date">September 13, 2020</span>

</small>
</div>
Expand Down

0 comments on commit 2c4ff29

Please sign in to comment.