Ungollum #2

> This information is a caryover from the original dn42 wiki. most is unsubstantiated and probably invalid now. Included here for historical reasons. Keys and other parameters can be found in the registry under `tinc-key` and `tinc-keyset`

first tinc cloud

================

172.22.255.161 fd04:de02:7af9::161 uves spline 64733

172.22.255.162 fd04:de02:7af9::162 petrus beta 64751

-------------- ------------------- --------- ----------- -----

A simple way to see all the active policies in the registry is to search the registry content for policy attributes:

grep -r ^policy data/inet{,6}num/

The [filter.txt](https://git.dn42.dev/dn42/registry/src/master/data/filter.txt) and [filter6.txt](https://git.dn42.dev/dn42/registry/src/master/data/filter6.txt) files within the registry detail the network wide constraints on what address ranges are in use together with the global limits on what can be announced.

To properly assign the right community to your peer, please reference the table below. If you are running your own network and peering internally, please also apply the communities inside your network.

## BGP community criteria

(64511, 1) :: latency \in (0, 2.7ms]

(64511, 2) :: latency \in (2.7ms, 7.3ms]

(64511, 3) :: latency \in (7.3ms, 20ms]

Propagation:

- - for latency pick max(received_route.latency, link_latency)

- - for encryption and bandwidth pick min between received BGP community and peer link

For example, if your peer is 12ms away and the link speed between you is 250Mbit/s and you are peering using OpenVPN P2P, then the community string would be (3, 24, 33).

Two utilites which measure round trip time and calculate community values automatically are provided, written in [ruby](https://github.com/Mic92/bird-dn42/blob/master/bgp-community.rb) and [C](https://github.com/nixnodes/bird/blob/master/misc/dn42-comgen.c).

$ ruby bgp-community.rb --help

USAGE: bgp-community.rb host mbit_speed unencrypted|unsafe|encrypted|pfs

-6, --ipv6 Assume ipv6 for ping

# 11 ms, 1000 mbit/s, pfs tunnel (updated: 2016-02-11)

import where dn42_import_filter(3,25,34);

export where dn42_export_filter(3,25,34);

### Route Origin

According to [this mail](https://lists.nox.tf/pipermail/dn42/2015-December/001259.html) these are the communities for route origin:

(64511, 41) :: Europe

(64511, 42) :: North America-E

(64511, 43) :: North America-C

(64511, 51) :: Asia-SE (TH,SG,PH,ID,MY)

(64511, 52) :: Asia-E (JP,CN,KR)

(64511, 53) :: Pacific

You need to add following lines to your config(s):

- `define DN42_REGION = $VALUE_FROM_ABOVE` to your node's config (where OWNAS and OWNIP are set)

## Example configurations

# /etc/bird/peers4/tombii.conf

protocol bgp tombii from dnpeers {

neighbor 172.23.102.x as 4242420321;

import where dn42_import_filter(3,24,33);

export where dn42_export_filter(3,24,33);

};

#/etc/bird/community_filters.conf

function update_latency(int link_latency) {

bgp_community.add((64511, link_latency));

reject;

}

Please remember to include /etc/bird/community_filters.conf in your bird.conf/birdc6.conf

# local configuration

######################

include "/etc/bird/filter4.conf";

include "/etc/bird/community_filters.conf";

***

This is not necessary for Debian Stretch, which currently ships the most recent version (1.6.3) in this repositories.

wget -O - http://bird.network.cz/debian/apt.key | apt-key add -

apt-get install lsb-release

echo "deb http://bird.network.cz/debian/ $(lsb_release -sc) main" > /etc/apt/sources.list.d/bird.list

apt-get update

apt-get install bird

# Example configuration

### IPv6

#/etc/bird/bird6.conf

protocol device {

scan time 10;

}

include "/etc/bird/peers6/*";

# /etc/bird/local6.conf

# should be a unique identifier, use same id as for ipv4

router id <GATEWAY_IP>;

fd00::/8{44,64} # ULA address space as per RFC 4193

];

}

# /etc/bird/peers6/<PEER_NAME>

protocol bgp <PEER_NAME> from dnpeers {

neighbor <PEERING_IP> as <PEER_AS>;

# if you use link-local ipv6 addresses for peering using the following

# neighbor <PEERING_IP> % '<INTERFACE_NAME>' as <PEER_AS>;

};

### IPv4

# /etc/bird/bird.conf

# Device status

protocol device {

};

include "/etc/bird/peers4/*";

#/etc/bird/local4.conf

# should be a unique identifier, <GATEWAY_IP> is what most people use.

router id <GATEWAY_IP>;

10.0.0.0/8{15,24} # Freifunk.net

];

}

# /etc/bird/peers4/<PEER_NAME>

protocol bgp <PEER_NAME> from dnpeers {

neighbor <PEERING_IP> as <PEER_AS>;

};

# Bird communities

You can add cron entries to periodically update the tables:

*/15 * * * * curl -sfSLR {-o,-z}/var/lib/bird/bird6_roa_dn42.conf https://dn42.burble.com/roa/dn42_roa_bird1_6.conf && chronic birdc6 configure

*/15 * * * * curl -sfSLR {-o,-z}/var/lib/bird/bird_roa_dn42.conf https://dn42.burble.com/roa/dn42_roa_bird1_4.conf && chronic birdc configure

Debian version:

*/15 * * * * curl -sfSLR -o/var/lib/bird/bird6_roa_dn42.conf -z/var/lib/bird/bird6_roa_dn42.conf https://dn42.burble.com/roa/dn42_roa_bird1_6.conf && /usr/sbin/birdc6 configure

*/15 * * * * curl -sfSLR -o/var/lib/bird/bird_roa_dn42.conf -z/var/lib/bird/bird_roa_dn42.conf https://dn42.burble.com/roa/dn42_roa_bird1_4.conf && /usr/sbin/birdc configure

then create the directory to make sure curls can save the files:

mkdir -p /var/lib/bird/

### Use RPKI ROA for bird2

* Download gortr

* Running gortr,need golang environment.

./gortr -verify=false -checktime=false -cache=https://dn42.burble.com/roa/dn42_roa_46.json

* run with docker

`docker pull cloudflare/gortr`

docker run --name dn42rpki -p 8282:8282 --restart=always -d cloudflare/gortr -verify=false -checktime=false -cache=https://dn42.burble.com/roa/dn42_roa_46.json

* Add this to your bird configure file,other ROA protocol must removed.

protocol rpki rpki_dn42{

roa4 { table dn42_roa; };

roa6 { table dn42_roa_v6; };

refresh keep 900;

expire keep 172800;

}

## Filter configuration

In your import filter add the following to reject invalid routes:

if (roa_check(dn42_roa, net, bgp_path.last) != ROA_VALID) then {

print "[dn42] ROA check failed for ", net, " ASN ", bgp_path.last;

reject;

}

Also, define your ROA table with:

roa table dn42_roa {

include "/var/lib/bird/bird_roa_dn42.conf";

};

**NOTE**: Make sure you setup ROA checks for both bird and bird6 (for IPv6).

bird can be remote controlled via the `birdc` command. Here is a list of useful bird commands:

$ birdc

BIRD 1.4.5 ready.

bird> configure # reload configuration

bird> show route protocol <somepeer> # shows the route they export to you

bird> show route export <somepeer> # shows the route you export to someone

...

# External Links

* detailed bird configuration from Mic92: https://github.com/Mic92/bird-dn42

* The same goes for `<OWNNETv6>`, but it takes an IPv6 subnet (Who'd have thought).

* Keep in mind that you'll have to enter both networks in the OWNNET{,v6} and OWNNETSET{,v6}, the two variables are required due to set parsing difficulties with variables.

################################################

# Variable header #

################################################

include "/etc/bird/peers/*";

# Route Origin Authorization

First, make sure the /etc/bird/peers directory exists:

# mkdir -p /etc/bird/peers

Then for each peer, create a configuration file similar to this one:

`/etc/bird/peers/<NEIGHBOR_NAME>.conf`:

protocol bgp <NEIGHBOR_NAME> from dnpeers {

neighbor <NEIGHBOR_IP> as <NEIGHBOR_ASN>;

}

protocol bgp <NEIGHBOR_NAME>_v6 from dnpeers {

neighbor <NEIGHBOR_IPv6>%<NEIGHBOR_INTERFACE> as <NEIGHBOR_ASN>;

}

Due to the special link local addresses of IPv6, an interface has to be specified using the %<if> syntax if a link local address is used (Which is recommended)

~~Send an email to `test@evenet.dn42` to check if your mail setup is correct.~~ This host will reply using the following

sieve filter:

require ["regex", "variables", "vacation-seconds"];

if header :contains "To" ["test@evenet.dn42"] {

if header :matches "Subject" "*" {

}

vacation :addresses ["test@evenet.dn42"] :seconds 60 :subject "Re: ${subject_was}" "Your dn42 email setup works!";

}

## Exim tips

If you use `smtpd_recipient_restrictions` you can use the following rule to white-list dn42 as sender.

This can circumvent certain rdns configuration failure or in case you use rbl lists:

smtpd_recipient_restrictions = permit_mynetworks,

permit_sasl_authenticated,

check_client_access cidr:/etc/postfix/dn42.cidr,

reject_non_fqdn_sender,

# ...

permit

#/etc/postfix/dn42.cidr

172.16.0.0/12 OK

10.0.0.0/8 OK

fc00::/7 OK

$ postmap /etc/postfix/dn42.cidr

### Receiving emails

## Upcoming

* dn42 IPv6 routing (probably)

Ask me if you want to know if I have implemented those items already.

# Configuration

firewall {

all-ping enable

broadcast-ping disable

/* Warning: Do not remove the following line. */

/* === vyatta-config-version: "config-management@1:dhcp-relay@1:dhcp-server@4:firewall@4:ipsec@3:nat@3:qos@1:quagga@2:system@4:ubnt-pptp@1:ubnt-util@1:vrrp@1:webgui@1:webproxy@1:zone-policy@1" === */

/* Release version: v1.3.0.4605130.131011.1754 */

## Create a temporary gre tunnel

ifconfig gre$INDEX create

ifconfig gre$INDEX tunnel $TUNNEL_SRC $TUNNEL_DST

ifconfig gre$INDEX inet $LOCAL $REMOTE netmask 0xffffffff

ifconfig gre$INDEX descr $DESCR

## Create a persistent gre tunnel

Add this to your `rc.conf`.

cloned_interfaces="$cloned_interfaces gre0"

ifconfig_gre0="10.0.0.1 10.0.0.2 netmask 0xffffffff tunnel 1.2.3.4 5.6.7.8 descr foo"

## pseudo interface

Populate [`/etc/hostname.gre0`](https://man.openbsd.org/hostname.if.5) with:

tunnel A.example.com D.example.net

inet6 fd42::/127

This will resolve FQDNs at parse time, set *A*'s and *D*'s IPs as source and destination tunnel address and set *A*'s assigned IP as point-to-point address on the interface.

Replace hostnames in the `tunnel` line with literal IPs if DNS is not available (at system boot).

## miscellaneous

Populate `/etc/sysctl.conf` with:

net.inet.gre.allow=1

Reboot or run `sysctl net.inet.gre.allow=1` to allow GRE packet processing.

-

At this point, `gre0` will be administratively *UP*:

$ ifconfig gre0

gre0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1476

index 22 priority 0 llprio 6

tunnel: inet6 2001:db8::a --> 2001:db9::d ttl 64 nodf ecn

inet6 fe80::221:28ff:fef9:c1d8%gre0 --> prefixlen 64 scopeid 0x16

inet6 fd42:: --> prefixlen 127

All traffic destined to `fd42::1/127` will be encapsulated and routed to *D*:

$ route show

[...]

Internet6:

ff01::%gre0/32 fe80::221:28ff:fef9:c1d8%gre0 Um 0 1 - 4 gre0

ff02::%gre0/32 fe80::221:28ff:fef9:c1d8%gre0 Um 0 1 - 4 gre0

[...]

$ route -n get fd42::1

route to: fd42::1

destination: fd42::1

flags: <UP,HOST,DONE,CLONED>

use mtu expire

3181 0 0

# Security

GRE may be protected with IPsec to encrypt and authenticate traffic, [OpenIKED](http://www.openiked.org/) can be used to establish an IKEv2 session between *A* and *D*.

- SSH Key: `auth: ssh-{rsa,ed25519} <key>`

Example: data/mntner/FOO-MNT

mntner: FOO-MNT

admin-c: FOO-DN42

tech-c: FOO-DN42

mnt-by: FOO-MNT

auth: pgp-fingerprint 0123456789ABCDEF0123456789ABCDEF01234567

source: DN42

### Create person objects

Example: data/person/FOO-DN42

person: John Doe

e-mail: john.doe@example.com

nic-hdl: FOO-DN42

mnt-by: FOO-MNT

source: DN42

---

- don't forget to set `mnt-by` to `<FOO>-MNT`, since you're managing this object on behalf of your organisation.

Example: data/organisation/ORG-EXAMPLE

organisation: ORG-FOO

org-name: Foo Organisation

admin-c: FOO-DN42

tech-c: FOO-DN42

mnt-by: FOO-MNT

source: DN42

### Guidelines for resource objects

If unsure, ask on the mailing list or IRC.

Example: data/aut-num/AS4242423999

aut-num: AS4242423999

as-name: AS-FOO-DN42

admin-c: FOO-DN42

tech-c: FOO-DN42

mnt-by: FOO-MNT

source: DN42

### Register a network prefix

or a small script is available: [ulagen.py](https://git.dn42.dev/netravnen/dn42-repo-utils/src/master/ulagen.py)

example: data/inet6num/fd35:4992:6a6d::_48

inet6num: fd35:4992:6a6d:0000:0000:0000:0000:0000 - fd35:4992:6a6d:ffff:ffff:ffff:ffff:ffff

cidr: fd35:4992:6a6d::/48

netname: FOO-NETWORK

mnt-by: FOO-MNT

status: ASSIGNED

source: DN42

#### IPv4 (Legacy)

**Note:** Reverse DNS works with _any_ prefix length, as long as your [recursive nameserver](/services/DNS) supports [RFC 2317](https://www.ietf.org/rfc/rfc2317.txt). Don't go for a /24 _just to have RDNS_.

example: data/inetnum/172.20.150.0_27

inetnum: 172.20.150.0 - 172.20.150.31

cidr: 172.20.150.0/27

netname: FOO-NETWORK

mnt-by: FOO-MNT

status: ASSIGNED

source: DN42

#### Create route objects

If you plan to announce your prefixes in dn42, which you probably want in most cases, you will also need to create a `route6` object for ipv6 prefixes and a `route` object for ipv4 prefixes. This information is used for Route Origin Authorization (ROA) checks. If you skip this step, your network will probably get filtered by most major peers. Checking ROA will prevent (accidental) hijacking of other people's prefixes.

example: data/route6/fd35:4992:6a6d::_48

route6: fd35:4992:6a6d::/48

origin: AS4242423999

max-length: 48

mnt-by: FOO-MNT

source: DN42

example data/route/172.20.150.0_27:

route: 172.20.150.0/27

origin: AS4242423999

mnt-by: FOO-MNT

source: DN42

#### DNS and Domain Registration

Domain names and nserver attributes must be lowercase.

example: data/dns/foo.dn42

domain: foo.dn42

admin-c: FOO-DN42

tech-c: FOO-DN42

nserver: ns2.foo.dn42 172.20.150.2

nserver: ns2.foo.dn42 fd35:4992:6a6d:53::2

source: DN42

You can also add DNSSEC delegations using `ds-rdata` attributes to your domain:

ds-rdata: 61857 13 2 bd35e3efe3325d2029fb652e01604a48b677cc2f44226eeabee54b456c67680c

For reverse DNS, add `nserver` attributes to you inet{,6}num objects:

inet6num: fd35:4992:6a6d:0000:0000:0000:0000:0000 - fd35:4992:6a6d:ffff:ffff:ffff:ffff:ffff

cidr: fd35:4992:6a6d::/48

netname: FOO-NETWORK

nserver: ns1.foo.dn42

nserver: ns2.foo.dn42

source: DN42

# Get some peers

## Kernel configuration

The FreeBSD GENERIC kernel lacks support for in-kernel IPsec processing. Add this two lines to your kernel config and (re-)build your own kernel.

If you're new to FreeBSD check Chapters [15.9.1](http://www.freebsd.org/doc/handbook/ipsec.html) and [9](http://www.freebsd.org/doc/handbook/kernelconfig.html) of the FreeBSD handbook.

options IPSEC #IP security

device crypto

Reboot into your new kernel.

## Userland configuration

Install the racoon daemon. It's included in the [security/ipsec-tools](http://www.freshports.org/security/ipsec-tools/) port.

Racoon is pain in the ass to configure the first time because it's error messages aren't helping and the complexity of IPsec. Don't let this stop you.

path pre_shared_key "/usr/local/etc/racoon/psk";

path certificate "/usr/local/etc/racoon/certs";

log info;

authentication_algorithm hmac_sha1;

}

## Define an IPsec security policy

Example policy on 1.2.3.4:

#!/usr/sbin/setkey -f

spdadd 1.2.3.4 5.6.7.8 gre -P out ipsec esp/transport//require;

spdadd 5.6.7.8 1.2.3.4 gre -P in ipsec esp/transport//require;

Change the direction on 5.6.7.8.

## Load the IPsec security policy into the IPsec security policy database

Load the policy with the setkey command.

setkey -f /etc/ipsec-tools.conf

Afterward check the policy database with:

setkey -DP

## Configure the racoon daemon

An example /etc/racoon/racoon.conf.

path pre_shared_key "/etc/racoon/psk.txt";

path certificate "/etc/racoon/certs";

log info;

authentication_algorithm hmac_sha1;

compression_algorithm deflate;

}

## Configure a GRE tunnel

Add this to /etc/network/interfaces:

auto gre1

iface gre1 inet tunnel

mode gre

endpoint 5.6.7.8

local 1.2.3.4

ttl 255

The keys are generated with plainrsa-gen.

Usage: plainrsa-gen [options]

-b bits Generate <bits> long RSA key (default=1024)

-f filename Filename to store the key to (default=stdout)

-i filename Input source for format conversion

-h Help

I'd probably go with 4096 bits.

in your racoon.conf:

path certificate "/etc/racoon/keys";

listen {

dh_group modp1024;

}

}

## Se also

## Quickstart

* Install pim6sd from here: https://github.com/troglobit/pim6sd/

cd /usr/src

git clone https://github.com/troglobit/pim6sd.git

cd pim6sd

./autogen.sh

./configure

make

* Find a peer who is already connected to the dn42 multicast backbone

* Calculate your personal, embedded-RP multicast prefix matching your network prefix via [RFC3956](https://tools.ietf.org/html/rfc3956)

* Example:

* Create a dummy interface to hold your calculated unicast Rendezvous Point address. This one needs to be reachable from within dn42. Also set "multicast on" on this dummy interface. Example:

# /etc/network/interfaces.d/pim6sd

auto pim-router-id

iface pim-router-id inet manual

post-up ip link set multicast on dev $IFACE

post-up ip -6 a a fd00:2001:db8::2/128 dev $IFACE

post-down ip link del $IFACE

* Create the configuration file:

# /etc/pim6sd.conf

# disable all interfaces by default

default_phyint_status disable;

# configure rendezvous point for the personal multicast prefix

cand_rp pim-router-id;

group_prefix ff7e:230:fd00:2001:db8::/96;

The `phyint` statement enables [PIM](https://tools.ietf.org/html/rfc7761) and [MLD](https://tools.ietf.org/html/rfc2710) on the target interface - by default all interfaces are in the disable state. Enable an interface if it is directed towards a multicast-capable peer or other multicast-capable routers in your autonomous system. Also enable it for downstream network segments with multicast listeners and senders, like for example your home (W)LAN segments.

On your router:

allow-hotplug pim-ns0

iface pim-ns0 inet manual

pre-up ip link add pim-ns0 type veth peer name pim-ns1

post-up ip netns exec pim-ns0 ip -6 r a default via fdd5:69d5:c530:1::1

post-down ip link del pim-ns0

post-down ip netns del pim-ns0

You can now switch into this test network namespace via "ip netns exec /bin/bash". Inside this network namespace you can try:

### Creating a test multicast listener

$ socat -u UDP6-RECV:1234,reuseaddr,ipv6-join-group="[ff7e:230:fdd5:69d5:c530::123]:eth0" -

### Creating a test multicast sender

First select which interface should be the default one for your multicast traffic. Then send multicast packets via ICMPv6:

$ ip -6 route add ff7e:230:fdd5:69d5:c530::/96 dev eth0 table local

$ ping6 -t 16 ff7e:230:fdd5:69d5:c530::123

The "-t 16", a hop-limit of 16, is important here as **by default all multicast traffic is usually send with a hop-limit of just 1**.

For example, if you've been assigned a public /48 prefix, and want to be reachable on DN42 aswell, you can use only ULA addresses from DN42 internally (or your own!), then map them to outside prefixes. Note that they'll need to all use the same prefix size to maintain the one-to-one mapping, so you may have to subnet the public prefix.

In Linux's netfilter, this can be implemented through the use of the NETMAP target, for the example above:

ip6tables -t nat -A POSTROUTING -d 2000::/3 -s <DN42-PREFIX>:<SUBNET>::/56 -j NETMAP --to <PUBLIC-PREFIX>:<SUBNET>::/56; # Map ULA to the public prefix for outgoing packets

ip6tables -t nat -A PREROUTING -s 2000::/3 -d <PUBLIC-PREFIX>:<SUBNET>::/56 -j NETMAP --to <DN42-PREFIX>:<SUBNET>::/56; # Map public prefix to ULA for incoming packets

### With Multiple Prefixes

## Number of routes by AS

IPv4:

#!/bin/bash

if [ "$1" = "config" ];then

echo graph_title Number of routes

else

ip r|sed 's/.* dev //;s/ .*//'|sort|uniq -c|grep as|awk '{print $2".value "$1}'

fi

IPv6:

#!/bin/bash

if [ "$1" = "config" ];then

echo graph_title Number of routes

else

ip -6 r|sed 's/.* dev //;s/ .*//'|sort|uniq -c|grep as|awk '{print $2".value "$1}'

fi

(hint: The difference just the -6 on the ip command)

## Graph routes and activity for every neighbour

https://github.com/luben/bird-multigraph-plugin

It's also possible to get notified by Munin when a problem with the peering persists. You have to define a critical value in line 138:

imported.critical 1:

This will send execute the command (set in munin-node.conf) to alert you, if the imported route count falls under 1.

You might also want to change line 125 from

graph_title $proto->{title} routes

to

graph_title $name routes

Example installation:

http://stats.tbspace.de/munin-cgi/munin-cgi-graph/tbspace.de/server.tbspace.de/dn42_crest_routes-day.png

## local host

Information such as ASN, router ID and allocated networks are required:

# macros

ASN="4242421234"

prefix-set mynetworks {

fd00:12:34::/48

}

These can be used in subsequent filter rules.

The local peer's announcements is then defined as follows:

# Generate routes for the networks our ASN will originate.

# The communities (read 'tags') are later used to match on what

# is announced to EBGP neighbors

network prefix-set mynetworks set large-community $ASN:1:1

## neighbors

For each neighbor its ASN and transfer ULA is required.

An optional description is provided such that [bgpctl(8)](http://man.openbsd.org/bgpctl.8) for example can be used with mnemonic names instead of AS numbers:

# peer A, transport over IPSec/GRE

$A_local="fd00:12:34:A::1"

$A_remote="fd00:12:34:A::2"

remote-as $A_ASN

descr "A"

}

## filter rules

**bgpd** blocks all BGP __UPDATE__ messages by default.

The last matching allow or deny rule decides what action is taken.

Start off with basic protection and sanity rules:

# deny more-specifics of our own originated prefixes

deny quick from ebgp prefix-set mynetworks or-longer

# filter out too long paths, establish more peerings instead

deny quick from any max-as-len 8

`quick` rules are considered the last matching rule, and evaluation of subsequent rules is skipped.

Allow own announcements:

# Outbound EBGP: only allow self originated networks to ebgp peers

# Don't leak any routes from upstream or peering sessions. This is done

# by checking for routes that are tagged with the large-community $ASN:1:1

allow to ebgp prefix-set kn large-community $ASN:1:1

Allow all remaining UPDATES based on **O**rigin **V**alidation **S**tates:

# enforce ROA

allow from ebgp ovs valid

Note how the `ovs` filter requires the `roa-set {...}` to be defined; see the `ROA` section below.

### path attributes

Besides `allow` and `deny` statements, filter rules can modify UPDATE messages, e.g.

# Scrub normal and large communities relevant to our ASN from EBGP neighbors

# https://tools.ietf.org/html/rfc7454#section-11

match from ebgp set { large-community delete $ASN:*:* }

# Honor requests to gracefully shutdown BGP sessions

# https://tools.ietf.org/html/rfc8326

match from any community GRACEFUL_SHUTDOWN set { localpref 0 }

# ROA

|[https://dn42.burble.com/roa/dn42_roa_obgpd_6.conf](https://dn42.burble.com/roa/dn42_roa_obgpd_6.conf) &nbsp; | &nbsp;IPv6 Only&nbsp; |

`/etc/dn42.roa-set` is the generated set:

roa-set {

fd00:12:34::/48 source-as 4242421234

fd00:ab:cd::/44 maxlen 64 source-as 4242427890

...

}

Include it in `/etc/bgpd.conf`:

# defines roat-set, see _rpki-client crontab

include "/etc/dn42.roa-set"

# Looking glass

This is mostly OpenBSD specific since [bgplg(8)](http://man.openbsd.org/bgplg.8) and [httpd(8)](http://man.openbsd.org/httpd.8) ship as part of the operating system.

ipv6 prefix-list vpn-in seq 15 deny any

#### Example filter list script

#!/bin/bash

vtysh -c 'conf t' -c "no ip prefix-list dn42"; #drop old prefix list

done < <(curl -s https://ca.dn42.us/reg/filter.txt | grep -e ^[0-9] | awk '{ print "ip prefix-list dn42 seq " $1 " " $2 " " $3 " ge " $4 " le " $5}' | sed "s_/\([0-9]\+\) ge \1_/\1_g;s_/\([0-9]\+\) le \1_/\1_g");

vtysh -c "wr" #write new prefix list

## show bpg session status

* no (vpn) connection at all exists with peer 64692

* a (vpn) connection with 4242421375 exists, but no bgp session

vtysh> show ip bgp summary

BGP router identifier 172.22.100.254, local AS number 64698

RIB entries 938, using 103 KiB of memory

....

172.23.64.1 4 4242421375 0 0 0 0 0 never Active

fe80::deca:fbad 4 64699 902 694 0 0 0 01:23:57 486

#### Finding the commit hash

`git log` will list all the recent commits and show the commit hash:

commit 6e2e9ac540e2e4e3c3a135ad90c8575bb8fa1784 (HEAD -> master)

Author: foo <foo@baz.com>

Date: Mon Jan 01 01:01:01 2020 +0000

Change some stuff

## Authentication with PGP Key

#### Using a public keyserver

- Use the following `auth` attribute in your `mntner` object:

auth: pgp-fingerprint <fingerprint>

Where `<fingerprint>` is your full 40-digit key fingerprint, without spaces.

- Ensure that your public key has been uploaded to a public keyserver, e.g. [SKS](https://sks-keyservers.net/), [OpenPGP](https://keys.openpgp.org/), [keybase](https://keybase.io/).

#### Adding to the registry

- Use the following `auth` attribute in your `mntner` object:

auth: PGPKEY-<fprint>

Where `<fprint>` is the last 8 digits from your key fingerprint.

- Create a `key-cert` object for your public key, using `PGPKEY-<fprint>` for the filename. Do browse the registry and check the existing objects for examples.

- Use `git commit -S` to commit and sign your change. See the [github guide](https://help.github.com/en/github/authenticating-to-github/signing-commits).

- If you have already committed your change, you can sign it using.

git commit --amend --no-edit -S

#### Verifying the signature

## Authentication using an SSH key

The generic format for authentication using an SSH key is as follows:

auth: ssh-<keytype> <pubkey>

There are examples below for each specific key type.

#### Generic process for signing with an SSH key

OpenSSH v8 introduced new functionality for creating signatures using SSH keys. If you have an older version, you can compile the latest version of ssh-keygen from the [openssh-portable repo](https://github.com/openssh/openssh-portable).

Use the following to sign the latest `<commit hash>` (that you found using `git log`)

echo "<commit hash>" | ssh-keygen -Y sign -f <private key file> -n dn42

Post the signature in to the 'Conversation' section of your pull request to allow the registry maintainers to verify it. It can help to also include the commit hash that you have signed, to avoid any confusion.

The following procedure will verify the signature (using the `<commit hash>`, your `<pubkey>` and the `<signature>` generated in the previous step.

Create a temporary file containing the signature

echo "<signature>" > sig.tmp

Create a temporary 'allowed users' file

echo "YOU-MNT ssh-<keytype> <pubkey>" > allowed.tmp

Verify the signature

echo "<commit hash>" | \

ssh-keygen -Y verify -f allowed.tmp -n dn42 -I YOU-MNT -s sig.tmp

### Authentication with an SSH RSA key

- Use the following `auth` attribute in your `mntner` object:

auth: ssh-rsa <pubkey>

Where `<pubkey>` is the ssh public key copied from your id_rsa.pub file.

#### Signing your commits

If you cannot use the generic SSH process described above then RSA signatures can also be created using openssl.

Use the following to sign your `<commit hash>` (that you found using `git log`)

openssl pkeyutl \

-sign \

-inkey ~/.ssh/id_rsa \

-in <(echo "<commit hash>") | base64

Post the signature in to the 'Conversation' section of your pull request to allow the registry maintainers to verify it. It can help to also include the commit hash that you have signed, to avoid any confusion.

#### Verifying the signature

The following script will verify the signature (using the `<commit hash>`, your rsa `<pubkey>` and the `<signature>` generated in the previous step.

openssl pkeyutl \

-verify \

-pubin \

-f <(echo "ssh-rsa <pubkey>")\

) \

-sigfile <(echo "<signature>" | base64 -d)

### Authentication with an SSH ed25519 key

- Use the following `auth` attribute in your `mntner` object:

auth: ssh-ed25519 <pubkey>

Where `<pubkey>` is the ssh public key copied from your id_ed25519.pub file.

#### Signing your commits

There is no alternative process for signing using ed25519 keys, you must use the generic process described above. The process only works with ssh-keygen versions >= v8.

Use the following to sign your `<commit hash>` (that you found using `git log`)

echo "<commit hash>" | ssh-keygen -Y sign -f ~/.ssh/id_ed25519 -n dn42

Post the signature in to the 'Conversation' section of your pull request to allow the registry maintainers to verify it. It can help to also include the commit hash that you have signed, to avoid any confusion.

The following procedure will verify the signature (using the `<commit hash>`, your ed25519 `<pubkey>` and the `<signature>` generated in the previous step.

Create a temporary file containing the signature

echo "<signature>" > sig.tmp

Create a temporary 'allowed users' file

echo "YOU-MNT ssh-ed25519 <pubkey>" > allowed.tmp

Verify the signature

echo "<commit hash>" | \

ssh-keygen -Y verify -f allowed.tmp -n dn42 -I YOU-MNT -s sig.tmp

### Authentication with an SSH ecdsa key

- Use the following `auth` attribute in your `mntner` object:

auth: ecdsa-sha2-nistp256 <pubkey>

Where `<pubkey>` is the ssh public key copied from your id_ecdsa.pub file.

#### Signing your commits

Convert your private ssh key to a file that openssl can read:

**DO THIS ON A COPY OF YOUR SSH KEY**

ssh-keygen -p -m pem -f <private key file copy>

Sign the commit hash using your ecdsa key, using openssl:

openssl pkeyutl -sign \

-inkey <converted key file> \

-in <(echo "<commit hash>") | base64

Post the signature in to the 'Conversation' section of your pull request to allow the registry maintainers to verify it. It can help to also include the commit hash that you have signed, to avoid any confusion.

#### Verifying the signature

The following script will verify the signature (using the `<commit hash>`, your ecdsa `<pubkey>` and the `<signature>` generated in the previous step.

openssl pkeyutl \

-verify \

-pubin \

-f <(echo "ecdsa-sha2-nistp256 <pubkey>")\

) \

-sigfile <(echo "<signature>" | base64 -d)

Modern versions of Windows do not support OSPF and manually adding static routes every time after a reboot is annoying. Below is a batch script you can edit and run to help make adding routes easier. This script assumes that your BGP router and Windows computer are on the same LAN.

@echo off

REM fill in YOUR network information

REM right click and RUN AS ADMIN

pause

ping %gateway6%

pause

If not, ask them about it.

Here we're gonna use aes256-sha256-modp1536

/ip ipsec peer

add address=1.1.1.1 comment=gre-dn42-peer dh-group=modp1536 \

enc-algorithm=aes-256 hash-algorithm=sha256 local-address=2.2.2.2 secret=PASSWORD

/ip ipsec policy

add comment=gre-dn42-peer dst-address=1.1.1.1/32 proposal=dn42 protocol=gre \

sa-dst-address=1.1.1.1 sa-src-address=2.2.2.2 src-address=2.2.2.2/32

### GRE

Pretty straightforward here

/interface gre

add allow-fast-path=no comment="DN42 somepeer" local-address=2.2.2.2 name=gre-dn42-peer \

remote-address=1.1.1.1

### IPs inside the GRE tunnel

Your peer most likely provided you with IP adresses for GRE tunnel.

#### IPv4

/ip address

add address=192.168.200.130/30 interface=gre-dn42-peer network=192.168.200.128

#### IPv6

Here we can use /127, so it's simple:

/ipv6 address

add address=fdc8:c633:5319:3300::41/127 advertise=no interface=gre-dn42-peer

If you configured everything correctly, you should be able to ping

OUT: 192.168.0.0/16 and 169.254.0.0/16, you really don't want to advertise this networks.

This filter will not only catch /8 or /16 networks, but smaller networks inside this subnets as well.

/routing filter

add action=discard address-family=ip chain=dn42-in prefix=192.168.0.0/16 prefix-length=16-32 protocol=bgp

add action=discard address-family=ip chain=dn42-in prefix=169.254.0.0/16 prefix-length=16-32 protocol=bgp

add action=discard address-family=ip chain=dn42-out prefix=192.168.0.0/16 prefix-length=16-32 protocol=bgp

add action=discard address-family=ip chain=dn42-out prefix=169.254.0.0/16 prefix-length=16-32 protocol=bgp

Now, if you want only DN42 connection, you can filter IN 10.0.0.0/8 (ChaosVPN / freifunk networks):

/routing filter

add action=discard address-family=ip chain=dn42-in prefix=10.0.0.0/8 prefix-length=8-32 protocol=bgp

### BGP

Now, for actual BGP configuration.

/routing bgp instance

set default disabled=yes

add as=YOUR_AS client-to-client-reflection=no name=bgp-dn42-somename out-filter=dn42-in \

router-id=1.1.1.1

Let's add some peers. Right now we have just one, but we still need two connections - to IPv4 and IPv6

IPv4:

/routing bgp peer

add comment="DN42: somepeer IPv4" in-filter=dn42-in instance=bgp-dn42-somename multihop=yes \

name=dn42-somepeer-ipv4 out-filter=dn42-out remote-address=192.168.200.129 remote-as=PEER_AS \

route-reflect=yes ttl=default

IPv6 (if needed):

/routing bgp peer

add address-families=ipv6 comment="DN42: somepeer IPv6" in-filter=dn42-in \

instance=bgp-dn42-somename multihop=yes name=dn42-somepeer-ipv6 out-filter=dn42-out \

remote-address=fd42:c644:5222:3222::40 remote-as=PEER_AS route-reflect=yes ttl=default

Also, as a note, Mikrotik doesn't deal well with BGP running over link-local addresses (the address starting with fe80). You need to use a fd42:: address in your BGP session, otherwise, BGP will not install any received route.

### BGP Advertisements

You want to advertise your allocated network (most likely), it's very simple:

/routing bgp network

add network=YOUR_ALLOCATED_SUBNET synchronize=no

You can repeat that with as much IPv4 and IPv6 networks which you own.

## Split DNS

Separate dns requests for dn42 tld from your default dns traffic with L7 filter in Mikrotik.

Change network and LAN GW to mach your network configuration.

/ip firewall layer7-protocol

add name=DN42-DNS regexp="\\x04dn42.\\x01"

/ip firewall nat

add action=src-nat chain=srcnat comment="NAT to DN42 DNS" dst-address=172.23.0.53 dst-port=53 protocol=udp src-address=192.168.0.0/24 to-addresses=192.168.0.1

add action=dst-nat chain=dstnat dst-address-type=local dst-port=53 layer7-protocol=DN42-DNS protocol=udp src-address=192.168.0.0/24 to-addresses=172.23.0.53 to-ports=53

Since version 6.47 have added functionality that can redirect DNS queries according to special rules. If you used to do Layer-7 rules in the firewall, now it's simple and elegant:

/ip dns static

add comment=DN42 forward-to=172.23.0.53 regexp=".*\\.dn42" type=FWD

You create the GRE interface in the same way the [Mikrotik Guide](/howto/mikrotik) does.

/interface gre

add allow-fast-path=no comment="DN42 somepeer" local-address=2.2.2.2 name=gre-dn42-peer \

remote-address=1.1.1.1

Next you add the /32 address on the interface. You can install this address on a loop interface (on RouterOS this means an empty bridge) if you plan to use the same address over several GRE tunnels or other OpenVPN interfaces.

/ip address add address=172.24.0.1/32 interface=gre-dn42-peer

Next, we add the direct route as next-hop using the interface

/ip route add distance=1 dst-address=172.26.2.2/32 gateway=gre-dn42-peer pref-src=172.24.0.1

At this point, the ping with the peer should work. Also, the bgp session can be established, but the routes will not work. We need a input filter to fix the next-hop routes.

/routing filter add chain=bgp-dn42-peer-in protocol=bgp set-in-nexthop-direct=gre-dn42-peer

if you have other global input chain filters, you should add a jump in the same chain, like this:

/routing filter add action=jump chain=bgp-dn42-peer-in protocol=bgp jump-target=bgp-global-dn42-input

If you haven't created the BGP session, create it now from the [Mikrotik guide](/howto/mikrotik#how-to-connect-to-dn42-using-mikrotik-routeros_bgp). Change the peer input filter to use the chain we've just created:

/routing bgp peer set bgp-dn42-somename in-filter=bgp-dn42-peer-in

With this fix, all the routes will have set next-hop the GRE interface and there will be no need to use RouterOS' recursive route resolve.

Check the routes with: