(aus https://github.com/amnezia-vpn/amnezia-client, GPL-3.0, ausgeschnitten von mir)

Es führt neun zusätzliche Paramater (Jc, Jmin, Jmax, S1, S2, H1, H2, H3, H4) ein.

Vanilla WireGuard

Das WireGuard-Protokoll besteht aus verschiedenen Nachrichten. Einige der wichtigsten Nachrichten sind die “Handshake Initation”, die “Handshake Response” und die eigentliche Datenpakete. Diese WireGuard Nachrichten haben alle einen Header, in welchem ihr Type definiert wird. Dieser wird mithilfe einer ganzen Zahl angegeben. Um eine WireGuard-Verbindung aufzubauen, wird im Allgemeinen vom Peer, welcher die Verbindung aufbauen will, eine “Handshake Initation” gesendet. Der andere Peer antwortet dann mit einer “Handshake Response”. Diese Pakete lassen sich mithilfe von DPI-Systemen erkennen und dann entsprechend blockieren. Dadurch wird der ganze WireGuard Tunnel verhindert und WireGuard ist dann blockiert.

Junk-Pakete

AmneziaWG kann vor dem Handshake Junk Pakete senden. Dabei handelt es sich um Pakete, welche zufällige Daten beinhalten und keinen Inhalt vermitteln sollen. Um die Art der Junk-Pakete zu definieren, gibt es drei Parameter: Jc, Jmin und Jmax.

Jc legt die Anzahl der Junk-Pakete fest. Ein Jc von drei bedeutet beispielsweise, dass vor dem Handshake drei Pakete mit Zufallsdaten gesendet werden sollen. Jc darf maximal 128 (inklusive) groß sein.

Jmin und Jmax legen die Größe der Junk-Pakete in Bytes fest - genauer die Größe des UDP-Payloads (die Größe des UDP-Header und des IP-Headers zählen also bei der Größenangabe nicht). Jmin legt dabei die minimale Größe des Payloads und Jmax die maximale Größe des Payloads fest. Die Größe des eigentlichen Payloads wird dann zufällig so gewählt, dass sie zwischen Jmin (inklusiv) und Jmax (inklusiv) liegt. Jmin muss kleiner oder gleich Jmax sein. Beide Werte dürfen maximal 1280 (inklusiv) Byte groß sein.

Wenn Jmin und Jmax gleich groß sind, liegt die Größe des Payloads zufällig zwischen Jmin und Jmax + 1.

Empfohlene Werte

Je nach Region und Umständen können verschiedene Werte empfohlen werden. Im Allgemeinen sollte Jc zwischen 3 (inklusive) und 10 (inklusive) sein. Es wird häufig 3 oder 4 verwendet. Für Jmin und Jmax wird 50 und 1000 bzw. 10 und 50 empfohlen.

Junk im Handshake

Zusätzlich zu den separaten Junk-Paketen werden auch Zufallsdaten vor den eigentlichen WireGuard Daten in der “Handshake Initation” und der “Handshake Response” hinzugefügt. Die Parameter S1 und S2 legen fest, wie viel Bytes an Junkdaten vor den eigentlichen WireGuard Daten platziert werden sollen. In der “Handshake Initation” werden S1 Bytes vor den eigentlichen Daten und in der “Handshake Response” S2 Bytes Zufallsdaten hinzugefügt. Diese Einstellung muss bei allen Peers gleich sein, damit jeder weiß, wo die eigentlichen sinnvollen Daten anfangen.

Empfohlene Werte

Für S1 und S2 wird ein zufälliger Wert zwischen 15 (inklusive) und 150 (inklusive) empfohlen. Dabei darf S1 + 56 nicht gleich S2 entsprechen.

Benutzerdefinierte Typen

Um zu identifizieren, um was für eine WireGuard Nachricht es sich handelt, wird im WireGuard Header ein Typ in Form einer ganzen Zahl angegeben. So hat die “Handshake Initation” den Typ 1 und die “Handshake Response” den Typ 2. Insgesamt gibt es (aktuell) vier festgelegte Typen. Da diese Typen fest definiert sind, eignen sie sich als Kriterium, um WireGuard Pakete zu erkennen. Daher ist es bei AmneziaWG möglich, die vordefinierten Typen zu überschreiben. Der Typ 1 wird zu H1, der Typ 2 wird zu H2, der Typ 3 wird zu H3 und der Typ 4 wird zu H4. Die H-Werte müssen sich voreinander unterscheiden.

Empfohlene Werte

Es wird ein zufälliger Wert zwischen 5 und 2^31-1=2147483647 bzw. 2^32-1=4294967295 (siehe Diskussion hier) empfohlen.

Rückwärtskompatibilität

AmneziaWG kann rückwärtskompatibel zu Vanille WireGuard verwendet werden. Dabei wird lediglich das Feature von Junkpaketen vor dem Handshake aktiviert und Features wie Junkdaten im Handshake und benutzerdefinierte Typen deaktiviert.

Dafür können folgende Parameter verwendet werden: S1 von 0, S2 von 0, H1 von 1, H2 von 2, H3 von 3 und H4 von 4.

Konfiguration

Die zusätzlichen Parameter können wie Adress- oder Schlüsselparameter in eine WireGuard Konfigurationsdatei geschrieben werden:

[Interface]
PrivateKey = uMnqnbbo+bbnnPVPjjyLqB72JHPvSOew/MqWxPz6PEg=
Address = 192.168.2.4/32

Jc = 3
Jmin = 50
Jmax = 1000
S1 = 20
S2 = 78
H1 = 39131278
H2 = 832138185
H3 = 1436957857
H4 = 1635877746

[Peer]
PublicKey = 8Yr++qyZzEL4zHS7CEgi+9zMm0d09qUA0xeqohNs8F8=
PresharedKey = fbDzRFA/PGH05Uwl9EFcI42F8KABRpSKoqS+Xv2qOl8=
Endpoint = 192.168.1.1:1234
AllowedIPs = fd00::/8

Paketierung

Linux

Unter Linux werden die awg-tools sowie die Kernel oder die Go-Implementierung benötigt. Für Debian gibt es ein von den AmneziaWG-Entwicklern bereitgestelltes Repository für die Tools und die Kernel-Implementierung. Für Arch Linux sind die Tools und die Go-Implementierung in AUR paketiert.

Android

Aktuell unterstützt in F-Droid nur WG Tunnel AmneziaWG.

Die AmneziaWG Entwickler stellen jedoch auch ein eigene VPN-App sowie einen AmneziaWG Client für Android bereit. Es wurde eine Anfrage an die AmneziaWG-Entwickler gestellt, den Client in F-Droid oder IzzyOnDroid aufzunehmen - aktuell ohne Rückmeldung von diesen. Des Weiteren scheint der AmneziaWG Client nicht von den Entwicklern, sondern Google signiert worden zu sein - falls bei Sicherheitsanwendung problematisch ist. Auch bei der Amnezia Client-App wurde eine Anfrage an die Entwickler sowie an F-Droid gesendet. Die Amnezia Client-App ist für IzzyOnDroid leider zu groß.

Offizielle Dokumentation

Eine genaue detaillierte offizielle Dokumentation wird es in vorhersehbarer Zukunft aus Sorge, dies würde Zensoren das Erkennen von AmenziaWG erleichtern vermutlich nicht geben.

Aussicht

Es gibt aktuell mehrere Anfragen, AmneziaWG in OpenWrt (Tools), MikroTik’s RouterOS, GL.iNet’s OpenWrt, DD-Wrt und andere Distributationen aufzunehmen.

Des Weiteren könnte geplant sein ein S3 bzw S4 für den WireGuard Anti-DoS-Mechanismus einzuführen.

(from https://github.com/amnezia-vpn/amnezia-client, GPL-3.0, cut out by me)

It introduces nine additional parameters (Jc, Jmin, Jmax, S1, S2, H1, H2, H3, H4).

Vanilla WireGuard

The WireGuard protocol consists of a variety of messages. Some of the most important messages are the “Handshake Initiation”, the “Handshake Response” and the actual data packets. These WireGuard messages all have a header in which their type is defined. This is specified using an integer. To establish a WireGuard connection, a “handshake initiation” is generally sent by the peer that wants to establish the connection. The other peer then responds with a “handshake response”. These packets can be recognized with the help of DPI systems and then blocked accordingly. This prevents the entire WireGuard tunnel and means that WireGuard is blocked.

Junk packets

AmneziaWG can send junk packets before the handshake. These are packets that contain random data and are not intended to communicate any information. There are three parameters to define the type of junk packets: Jc, Jmin and Jmax.

Jc defines the number of junk packets. For example, a Jc of three means that three packets with random data should be sent before the handshake. The maximum size of Jc is 128 (inclusive).

Jmin and Jmax define the size of the junk packets in bytes - more precisely the size of the UDP payload (the size of the UDP header and the IP header do not count when specifying the size). ‘Jmin’ specifies the minimum size of the payload and ‘Jmax’ the maximum size of the payload. The size of the actual payload is then randomly selected so that it lies between Jmin (inclusive) and Jmax (inclusive). Jmin must be less than or equal to Jmax. Both values may be a maximum of 1280 (inclusive) bytes in size.

If Jmin and Jmax are the same size, the size of the payload lies randomly between Jmin and Jmax + 1.

Recommended values

Depending on the region and circumstances, different values may be recommended. In general, ‘Jc’ should be between 3 (inclusive) and 10 (inclusive). Often 3 or 4 is used. For Jmin and Jmax, 50 and 1000 or 10 and 50 are recommended respectively.

Junk in the handshake

In addition to the separate junk packets, random data is also added before the actual WireGuard data in the “Handshake initiation” and the “Handshake response”. The parameters ‘S1’ and ‘S2’ define how many bytes of junk data are to be placed before the actual WireGuard data. In the “Handshake Initiation”, S1 bytes are added before the actual data and in the “Handshake Response” S2 bytes of random data. This setting must be the same for all peers so that everyone knows where the actual meaningful data begins.

Recommended values

A random value between 15 (inclusive) and 150 (inclusive) is recommended for S1 and S2. However, S1 + 56 must not equal S2.

User-defined types

To identify what type of WireGuard message it is, a type is specified in the WireGuard header in the form of an integer. For example, the “Handshake Initiation” is type 1 and the “Handshake Response” is type 2. There are (currently) a total of four defined types. As these types are fixed, they are suitable as a criterion for recognizing WireGuard packets. It is therefore possible to overwrite the predefined types in AmneziaWG. Type 1 becomes H1, type 2 becomes H2, type 3 becomes H3 and type 4 becomes H4. The H values must be different from each other.

Recommended values

A random value between 5 and 2^31-1=2147483647 or 2^32-1=4294967295 (see discussion here) is recommended.

Backward compatibility

AmneziaWG can be used backwards-compatible with Vanille WireGuard. Only the feature of junk packets before the handshake is activated and features such as junk data in the handshake and user-defined types are deactivated.

The following parameters can be used for this: ‘S1’ of 0, ‘S2’ of 0, ‘H1’ of 1, ‘H2’ of 2, ‘H3’ of 3 and ‘H4’ of 4.

Configuration

The additional parameters can be written to a WireGuard configuration file in the same way as address or key parameters:

[Interface]
PrivateKey = uMnqnbbo+bbnnPVPjjyLqB72JHPvSOew/MqWxPz6PEg=
Address = 192.168.2.4/32

Jc = 3
Jmin = 50
Jmax = 1000
S1 = 20
S2 = 78
H1 = 39131278
H2 = 832138185
H3 = 1436957857
H4 = 1635877746

[Peer]
PublicKey = 8Yr++qyZzEL4zHS7CEgi+9zMm0d09qUA0xeqohNs8F8=
PresharedKey = fbDzRFA/PGH05Uwl9EFcI42F8KABRpSKoqS+Xv2qOl8=
Endpoint = 192.168.1.1:1234
AllowedIPs = fd00::/8

Packaging

Linux

Under Linux, the awg-tools and the Kernel or the Go implementation are required. For Debian there is a repository provided by the AmneziaWG developers for the tools and the kernel implementation. For Arch Linux, the Tools and the Go implementation are packaged in AUR.

Android

Currently only WG Tunnel supports AmneziaWG in F-Droid.

However, the AmneziaWG developers also provide an own VPN app and an AmneziaWG client for Android. A request has been made to the AmneziaWG developers to include the client in F-Droid or IzzyOnDroid - currently without feedback from the developers. Furthermore, the AmneziaWG client seems to have been not signed by the developers, but by Google - which is problematic in the case of a security application. A request was also sent to the developers and to F-Droid for the Amnezia client app. The Amnezia client app is unfortunately too large for IzzyOnDroid.

Official documentation

There will probably be no detailed official documentation in the foreseeable future out of concern that this would make it easier for censors to recognize AmenziaWG.

Outlook

There are currently several requests to include AmneziaWG in OpenWrt (Tools), MikroTik’s RouterOS, GL.iNet’s OpenWrt, DD-Wrt and other distributions.

Furthermore, it could be planned to introduce an S3 or S4 for the WireGuard Anti-DoS mechanism.

Begegnung mit RTT

Als ich das erste Mal davon gehört habe, fand ich die Funktion natürlich sehr toll und dachte nicht, dass man beim RTT Feature mehr als “aus” oder “ein” einstellen kann. Tatsächlich gibt es jedoch vier einstellbare Optionen mit Dokumentation. Diese Dokumentation kann für Anfänger in diesem Bereich, wie mir, jedoch schwer zu verstehen sein. Es gibt jedoch eine Mailingliste, auf der man sehr nette Hilfe erhält.

bird’s babel Implementierung bekommt das RTT Feature

Das RTT Feature war anfangs nur in babeld - der Referenzimplementierung - verfügbar. Es wurde jedoch auch mit Version 2.14 in bird implementiert. Ich selber hatte Interesse an babel RTT, da ich im dn42 bird als Routing Dämon und babel als IGP verwende. Des Weiteren bin ich Teilnehmer im CRXN, welches als primäres Routing Protokoll ganz auf babel setzt.

RX Kosten = RTT

Es gibt insgesamt vier Konfigurationsoptionen: rtt-min, rtt-max, rtt-cost in bird bzw. max-rtt-penalty in babeld und rtt-decay.

Als ich für das CRXN das RTT das erste Mal konfigurierte, war ich sehr froh, folgenden Schnipsel gefunden zu haben (ich kann mich leider nicht mehr erinnern, wo): rxcost 1 rtt-min 1 rtt-max 1001 max-rtt-penalty 1000. Diese Zeile bewirkt kurz gesagt, dass die RX-Kosten gleich der Round Trip Time sind und ab einer RTT von 1s nicht mehr höher gehen.

Juliusz, der Entwickler von babel, schrieb dazu:

It is of course possible that these values are not appropriate in your network; however, I fear that the extremely aggressive values that you describe above may cause unnecessary oscillations, especially since BIRD does not yet implement hysteresis on metrics.

Seit diesem Moment an habe ich überlegt, welche Werte sinnvoller bzw. besser wären. Da ich jedoch recht faul bin und nicht den ganzen Tag mit Netzwerken spielen kann, hat es einige Zeit gedauert, bis ich weiter nachgefragt habe.

Konfigurationsoptionen

Um gute Parameter zu wählen, ist es jedoch notwendig, zu verstehen, was die einzelnen Konfigurationsoptionen bedeuten:

rtt-min

rtt-min gibt an, ab welchem RTT, das RTT die RX-Kosten beeinflussen sollen. Wenn der aktuelle RTT also unter rtt-min ist, werden die RX-Kosten nicht verändert.

Juliusz sagte dazu:

rtt-min should be chosen so that all links below rtt-min are local – the idea is that below rtt-min, it’s not worth optimising the path. The default value (10ms) should be fine in most networks.

Beispiel: Ein rtt-min von 10ms bedeutet, dass das RTT die RX-Kosten erst beeinflusst, wenn der RTT größer 10ms. Wenn der RTT aktuell also aktuell 6ms ist, bleiben die RX-Kosten vom RTT unbeeinflusst. Wenn der aktuelle RTT allerdings beispielsweise 30ms ist, werden die Kosten erhöht.

Wahl: Das rtt-min sollte so gewählt werden, dass es nicht kleiner ist als die minimale lokale RTT ist. Wenn also zwei Computer im gleichen Datenzentrum eine RTT von 4ms aufweisen, sollte die rtt-min nicht kleiner als 4ms sein. Ich persönlich würde des Weiteren die rtt-min nicht kleiner als den Standardwert von 10ms machen.

rtt-max

rtt-max gibt an, ab welchem RTT die RX-Kosten nicht mehr beeinflusst werden sollen - also ab welchem RTT die maximalen RTT-spezifischen Kosten addiert werden sollen.

Juliusz sagte dazu:

rtt-max should be larger than all good links in your network – the idea is that above rtt-max, it’s no longer worth optimising the path. In your case, you might want to increase the value to 350ms or so.

Beispiel: Wenn rtt-max 120ms und der aktuelle RTT 150ms ist, dass, die RX-Kosten bereits maximal sind und nicht mehr steigen. Ab dem rtt-max sind alle Links “gleich schlecht” und sollten vermieden werden.

Wahl: Das rtt-max sollte so gewählt werden, dass es die maximale RTT (am besten mit etwas Luft nach oben) im Netzwerk darstellt. Wenn die maximale RTT im Netzwerk also zwischen 100ms und 130ms variiert, so könnte man 150ms als rtt-max wählen.

rtt-cost / max-rtt-penalty

Bei rtt-max habe ich geschrieben, dass RTL-spezifische Kosten zu den RX-Kosten addiert werden, jedoch nie erwähnt, wie groß diese eigentlich sind. Dies kann man mit rtt-cost in bird bzw. max-rtt-penalty in babeld festlegen. Wenn der RTT größer als rtt-max ist, wird zu den RX-Kosten also der Wert von rtt-cost addiert. Ansonsten wird der Wert beginnend beim RTT von rtt-min linear skaliert addiert.

Juliusz sagte dazu:

Max-rtt-penalty controls how much Babel will prefer routes with many links but low RTT to routes with few links but hight RTT. The default is fairly conservative, meaning that RTT has only a very small influence on routing. You should set it to 96*n where n is the maximum number of extra links that you’re willing to take in order to avoid one high-RTT link.

Beispiel: Die RX-Kosten sind mit 96 konfiguriert, die rtt-cost mit 100 und rtt-max mit 500. Die RTT ist nun 643ms. Dies bedeutet, dass die RTT größer als rtt-max ist und somit die volle rtt-cost auf die RX-Kosten addiert werden. Die effektiven Kosten belaufen sich also auf 96+100=196.

Wahl: Es gilt, dass rtt-cost/(rtt-max-rtt-min) angibt, in welchem Intervall abhängig vom RTT sich die RX-Kosten erhöhen. Bei rtt-min von 10, rtt-max von 1000 und rtt-cost von 192, erhöhen sich beispielsweise die RX-Kosten jede 5ms im RTT um Eins. Des Weiteren sollte man bedenken, dass ein zu hoher Wert und die Verwendung von einer nicht vollständigen RTT Implementierung zu Schwingungen und im schlimmsten Fall dann auch zu Route Flapping führen könnte. Ich persönlich empfehle daher, die rtt-cost niedriger als die rtt-max zu wählen.

rtt-decay

rtt-decay gibt an, inwiefern ältere RTT Proben bei der Berechnung des RTT berücksichtigt werden sollen. Ein höheres Decay bedeutet, dass ältere RTT Proben verworfen bzw. nicht mehr berücksichtigt werden sollen. Ein niedriges Decay bedeutet dagegen, dass mehr ältere RTT Proben berücksichtigt werden sollen.

Juliusz sagte dazu:

As to rtt-decay, the default value should be fine unless you have a mobile network. Increase it in order to react faster to RTT variations, at the risk of route flaps every time the network has a hiccup.

Wahl: Im Zweifelsfall: Nehme den Standardwert. Wenn du mobil (beispielsweise Mobilfunk oder Bahn-WLAN) unterwegs bist, empfiehlt es sich, das Decay zu erhöhen (beispielsweise auf 150).

Konfiguration

In folgenden Beispielen wird das Interface crxnbandura mit rtt-min von 10ms, rtt-max mit 1000ms bzw. 1s, rtt-cost von 192 und rtt-decay von 60 konfiguriert.

bird:

protocol babel {
    interface "crxnbandura" {
        type tunnel;
        rtt cost 192;
        rtt min 10 ms;
        rtt max 1000 ms;
        rtt decay 60;
    };

    ipv6 { /* Stuff */ }
}

Bei bird besteht die Möglichkeit als Einheit entweder ms für Milisekunden oder s für Sekunden zu wählen. Es ist verpflichtend eine Einheit anzugeben.

babeld:

interface crxnbandura type tunnel
interface crxnbandura rtt-min 10
interface crxnbandura rtt-max 1000
interface crxnbandura max-rtt-penality 192

Oder in Kurzform:

interface crxnbandura type tunnel rtt-min 10 rtt-max 1000 max-rtt-penality 192

Andere Netzwerke

re6st mesh network

Das re6st mesh network verwendet den Standardwert (10ms) als rtt-min, 500ms als rtt-max, 5000 als rtt-cost und 125 als rtt-decay. Dabei sollte man, wie von Juliusz angemerkt, bedenken, dass 5000 als rtt-cost recht hoch ist.

Meine Werte

Da ich aktuell selber noch experimentiere, kann ich selber nur schlecht eine Empfehlung abgeben. Aktuell verwende ich im CRXN 10ms als rtt-min, 1000ms als rtt-max und 2 * 96 als rtt-cost. Dazu sollte man sagen, dass der rtt-max Wert vermutlich übertrieben ist, da ich als maximale Link RTT etwa 350ms habe. Des Weiteren überlege ich auf 3 * 96 für rtt-cost umzusteigen, um die tatsächliche RTT besser widerzuspiegeln.

Encounter with RTT

When I first heard about it, I naturally thought it was a great feature and didn’t think you could set more than “off” or “on” for the RTT feature. However, there are actually four adjustable options with documentation. However, this documentation can be difficult to understand for beginners like me. However, there is a mailing list where you can get help.

bird’s babel implementation gets the RTT feature

The RTT feature was initially only available in babeld - the reference implementation. However, it was also implemented in bird with version 2.14. I myself was interested in babel RTT because I use bird as routing daemon and babel as IGP in dn42. I am also a participant in CRXN, which relies entirely on babel as its primary routing protocol.

RX costs = RTT

There are a total of four configuration options: rtt-min, rtt-max, rtt-cost in bird or max-rtt-penalty in babeld and rtt-decay.

When I configured the RTT for the CRXN for the first time, I was very happy to have found the following snippet (unfortunately I can no longer remember where): rxcost 1 rtt-min 1 rtt-max 1001 max-rtt-penalty 1000. In short, this line has the effect that the RX costs are equal to the round trip time and do not go any higher from an RTT of 1s.

Juliusz, the developer of babel, wrote about this:

It is of course possible that these values are not appropriate in your network; however, I fear that the extremely aggressive values that you describe above may cause unnecessary oscillations, especially since BIRD does not yet implement hysteresis on metrics.

From that moment on, I have been thinking about which values would be more practical or better. However, as I am quite lazy and can’t play with networks all day, it took me some time to ask further.

Configuration options

In order to choose good parameters, however, it is necessary to understand what the individual configuration options mean:

rtt-min

rtt-min specifies the RTT from which the RTT should influence the RX costs. So if the current RTT is below rtt-min, the RX costs are not changed.

Juliusz said:

rtt-min should be chosen so that all links below rtt-min are local – the idea is that below rtt-min, it’s not worth optimising the path. The default value (10ms) should be fine in most networks.

Example: An rtt-min of 10ms means that the RTT only influences the RX costs when the RTT is greater than 10ms. So if the RTT is currently 6ms, the RX costs remain unaffected by the RTT. However, if the current RTT is 30ms, for example, the costs are increased.

Choice: The rtt-min should be chosen so that it is not smaller than the minimum local RTT. So if two computers in the same data center have an RTT of 4ms, the rtt-min should not be less than 4ms. I personally would not make the rtt-min smaller than the default value of 10ms.

rtt-max

rtt-max specifies from which RTT onwards the RX costs should no longer be influenced - i.e. from which RTT onwards the maximum RTT-specific costs should be added.

Juliusz said:

rtt-max should be larger than all good links in your network – the idea is that above rtt-max, it’s no longer worth optimising the path. In your case, you might want to increase the value to 350ms or so.

Example: If rtt-max is 120ms and the current RTT is 150ms, the RX cost is already at its maximum and will not increase. From rtt-max onwards, all links are “equally bad” and should be avoided.

Choice: The rtt-max should be chosen so that it represents the maximum RTT (preferably with a little room for variation) in the network. So if the maximum RTT in the network varies between 100ms and 130ms, you could choose 150ms as the rtt-max.

rtt-cost / max-rtt-penalty

With rtt-max I wrote that RTL-specific costs are added to the RX costs, but never mentioned how large these actually are. This can be specified with rtt-cost in bird or max-rtt-penalty in babeld. If the RTT is greater than rtt-max, the value of rtt-cost is added to the RX costs. Otherwise, the value is added linearly scaled starting at the RTT of rtt-min.

Juliusz said:

Max-rtt-penalty controls how much Babel will prefer routes with many links but low RTT to routes with few links but hight RTT. The default is fairly conservative, meaning that RTT has only a very small influence on routing. You should set it to 96*n where n is the maximum number of extra links that you’re willing to take in order to avoid one high-RTT link.

Example: The RX costs are configured with 96, the rtt-cost with 100 and rtt-max with 500. The RTT is now 643ms. This means that the RTT is greater than rtt-max and therefore the full rtt-cost is added to the RX costs. The effective cost is therefore 96+100=196.

Choice: It applies that rtt-cost/(rtt-max-rtt-min) indicates the RTT interval in which the RX costs increase by one. For example, with rtt-min of 10, rtt-max of 1000 and rtt-cost of 192, the RX costs increase by one every 5ms in the RTT. You should also bear in mind that too high a value and the use of an incomplete RTT implementation could lead to oscillations and, in the worst case, to route flapping. I therefore personally recommend setting the rtt-cost lower than the rtt-max.

rtt-decay

rtt-decay specifies the extent to which older RTT samples should be taken into account when calculating the RTT. A higher decay means that older RTT samples should be discarded or no longer taken into account. A low decay, on the other hand, means that more older RTT samples should be taken into account.

Juliusz said:

As to rtt-decay, the default value should be fine unless you have a mobile network. Increase it in order to react faster to RTT variations, at the risk of route flaps every time the network has a hiccup.

Choice: If in doubt, use the default value. If you are on the move (e.g. mobile phone or WLAN in train), it is advisable to increase the decay (e.g. to 150).

Konfiguration

In the following examples, the interface crxnbandura is configured with rtt-min of 10ms, rtt-max of 1000ms or 1s, rtt-cost of 192 and rtt-decay of 60.

bird:

protocol babel {
    interface "crxnbandura" {
        type tunnel;
        rtt cost 192;
        rtt min 10 ms;
        rtt max 1000 ms;
        rtt decay 60;
    };

    ipv6 { /* Stuff */ }
}

For bird, it is possible to select either ms for milliseconds or s for seconds as the unit. It is mandatory to specify a unit.

babeld:

interface crxnbandura type tunnel
interface crxnbandura rtt-min 10
interface crxnbandura rtt-max 1000
interface crxnbandura max-rtt-penality 192

Or in short form:

interface crxnbandura type tunnel rtt-min 10 rtt-max 1000 max-rtt-penality 192

Other networks

re6st mesh network

The re6st mesh network uses the default value (10ms) as rtt-min, 500ms as rtt-max, 5000 as rtt-cost and 125 as rtt-decay. As noted by Juliusz, you should bear in mind that 5000 as rtt-cost is quite high.

My values

As I am currently still experimenting myself, it is difficult for me to make a recommendation. Currently I use 10ms as rtt-min, 1000ms as rtt-max and 2 * 96 as rtt-cost in the CRXN. It should be said that the rtt-max value is probably excessively high, as I have a maximum link RTT of around 350ms. I am also considering switching to 3 * 96 for rtt-cost to better reflect the actual RTT.

heute bin ich dem CRXN Netwerk beigetreten. Das CRXN ist ähnlich wie das dn42, jedoch mit vier Unterschieden:

• Es verwendet nur IPv6
• Es verwendet das Routing Protokoll babel
• Es ist deutliche klein, was man an der Anzahl der Prefixe sehen kann
• Es wird fastd als Tunnel verwendet

Ich wollte das CRXN auf den gleichen Knoten haben, die ich auch das dn42 Netzwerk benutzte, jedoch dürften sich die Routen der beiden Netzwerke nicht vermischen, da ihre Registries nicht miteinander synchronisiert sind, andere Routingprotokolle verwenden und allgemein keine Interkonnectivität zwsichen ihnen vorhanden ist. Dies stellte eine kleine Herausforderung da.

Des Weiteren ist es im CRXN aktuell (noch) nicht möglich die Routen zu validieren, sodass Route Hjacking oder ähnliches recht leicht ist.

Es verwendet nur IPv6

Ich halte für eine gute Entscheidung, nur IPv6 zu verwenden. Nicht umsonst ist IPv6 die Zukunft. CRXN verwendet den ULA Bereich. Dieser entspricht dem privaten IPv4 Bereich. Dieser Bereich ist so groß, dass es (wenn die Prefixe zufällig generiert werden) im Normalfall zu keiner Kollision zum Beispiel mit dem dn42 kommt.

Es verwendet das Routingprotokoll babel

Babel wird eigentlich für IGP eingesetzt, jedoch ist es auch möglich Netze damit zu verbinden. Das Routing wird so effizienter, da als Auswahlkriterium eine Metric bentzt wird, welche in der Referenzimplementierung (babeld), der Latenz in ms entspricht. Somit wird immer der Pfad mit der kürzesten Latenz verwendet. Auch bird und frr haben babel mittlerweile implementiert, jedoch wird dort die Metric (leider) nicht automatisch berechnet. Ich habe es so gemacht, dass ich diese zu Anfang eines Peering messe und dann manuell eintrage. Das Problem daran ist, dass sich Latenzen bedauerlicherweise verändern können - beispielsweise wenn sich das Underlay-Netzwerk (hier das Clearnet) verändert.

Es ist klein

Wenn man keine strenge Validierung der Routen vornimmt, erhält man ca. 20 IPv6 Prefixe. Wenn man eine strengere Validierung vornimmt, erhält man etwa 10 Prefixe. Bei dn42 (+ NeoNetwork + IC-VPN + ChaosVPN) sind es ca. 600 Prefixe.

Es verwendet fastd

In dn42 wird normalerweise WireGuard zum Peering benutzt, da dies einfach zu konfigurieren ist und eine gute Sicherheit bietet. Davor wurde OpenVPN verwendet. OpenVPN ist einmal langsamer und einmal unsicherer, wenn man es mit einem Preshared Key (PSK) verwendet. fastd wird auch von Freifunk / IC-VPN verwendet. Es handelt sich dabei auch um eine Tunnellösung, welche auch mit guter Sicherheit verschlüsselt ist. In Gegensatz zu WireGuard operiert es auf Layer 2 des OSI-Modells (MAC-Adressen), wobei WireGuard auf Layer 3 (IP-Adressen) arbeitet.

Mehrere Netze auf einem Knoten

Mehrere Netze auf einem Knoten - dafür gibt es verschiedene Lösungsansätze. Eine Lösung wäre mehrere bird Instanzen zu verwenden. Für diese Lösung fällt mir das Wissen und ist damit für mich zu aufwendig. Ein anderer Lösungsansatz wäre die Verwendung von verschiedenen Routing Tabellen. So könnte man mit ipv6 table crxn; eine zweite IPv6 Routing Table erstellen. Problematisch wird dieser Ansatz, wenn man - wie ich - mehrere Knoten hat, welche über iBGP verbunden ist. Ich müsste als doppelt so viele BGP Sessions als jetzt haben, da in einer BGP Session nicht mehrere Routing Tabellen übertragen werden können. Eine andere Möglichkeit ist das “markieren” von Routen. Beim Import würde die dn42 Routen mit “dn42” markiert und die CRXN Routen mit “crxn”. Beim Export könnte man nun jede Route dem entsprechenden Netz zuordnen. Es gibt verschiedene Möglichkeiten, eine Route zu markieren. Die bekannteste ist wohl BGP Communities bzw. Large BGP Communities (bei 32-Bit ASNs) anzuhängen. Da dn42 Peers jedoch nur dn42 Routen erwarten, ist die Information, dass es sich um dn42 Routen handelt, unnötig und würde nur Platz in der Globalen Routing Tabelle einnehmen. Dies bedeutet, man müsste die entsprechenden Communities beim Export löschen. Das nächste Problem mit Communities war, dass ich zwei AS-Nummern habe. Einmal von dn42 und einmal vom NeoNetwork. Mit welcher sollte ich die Routen markieren? Da es nur intern wäre, wäre es egal. Eine Alternative zu den BGP communities stellen benutzerdefinierte BGP Attribute dar. Ein BGP Attribut ist beispielsweise bgp_local_pref oder bgp_med, jedoch kann man auch selber welche definieren. Für diese Möglichkeit habe ich mich entschieden. Ich habe mit attribute int netid; ein neues ganzzahliges Attribut mit dem Namen netid erstellt. Wenn die Route vom dn42 Netz bekommt, bekommt sie die ID 1. Wenn die Route vom CRXN Netz kommt, bekommt sie die ID 2. Entsprechend muss ich das andere Netz beim Export filtern. Somit habe ich alle Routen in einer Routing Tabelle und entsprechend markiert.

Fehlende Validierung der Routen

In dn42 kann man sich aus dem Registry ROA Einträge erzeugen lassen. In diesen steht drin, welches AS, welche Prefixe und mit welcher Länge announcen darf. In CRXN gibt es jedoch keine AS-Nummern, weshalb eine ROA Filterung nicht in Frage kommt. Als Registry gibt es lediglich eine entitydb, in welcher der Name des Netzwerkes und der Prefix des Netzwerkes angegeben ist. Die Dateien darin befinden sich im JSON Format. Die einzige Validierung, welche ich somit vornehmen kann, ist zu sagen, dass nicht-CRXN Prefixe nicht exportiert werden. Die Prefixe, welche erlaubt sind, parse ich mir wiederum aus der entitydb. Alle anderen Routen verwerfe ich.

Zukunft

Geplant ist eine eventuelle Vernetzung mit dem dn42. Dabei soll es eine ASN geben, welche die Berechtigung hat, alle CRXN Routen zu exportieren. Mit entsprechender Konfiguration könnte man so mehrere Gateways zwischen dem dn42 und dem CRXN herstellen. Es bleibt spannend.

Links

• entitydb: https://codeberg.org/CRXN/entitydb
• CRXN Dokumentation: http://deavmi.assigned.network/projects/crxn/
• CRXN Dokumentation Mirror: https://crxn.de/docs/
• fastd Dokumentation: https://fastd.readthedocs.io/en/stable/index.html

Folgendes sind Kriterien in bird:

1. Es wird die Route mit dem höchsten Gewicht präferiert. Dafür gibt es in bird den Wert preference. Dieser wird zum Beispiel zur Bevorzugung von IGP über EGP benutzt - so wird beispielsweise Babel über BGP bevorzugt.
2. Es wird die Route mit der höchsten lokalen Präferenz ausgewählt. Dies kann man im Import-Filter mit der Variable bgp_local_pref beeinflussen. Die Standardpräferenz ist 100.
3. Die Route mit dem kürzesten AS Pfad wird bevorzugt. Dies ist in allen Implementierungen ein entscheidenes Kriterium. Der Pfad gibt grundsätzlich (Ausnahme: Path Prepending) an, wie viele autonome Systeme durchquert werden müssen, um das Ziel zu erreichen.
4. Danach wird ein sehr selten benutzter Wert überprüft: der Ursprung. Über IGP empfangende Routen werden präferiert. In bird wird mittlerweile jedoch preference benutzt.
5. Falls man mehrere Peerings mit demselben autonomen System hat, wird der kleinste Multiple Exit Discriminator (MED) bevorzugt. Falls man beispielsweise einmal dezidiert und einmal über einen IXP verbunden ist, so möchte man im Allgemeinen die dezidierte Leitung bevorzugen, da diese nicht geteilt werden muss. Daher bekommen Routen, welche darüber empfangen wurde, eine kleinere MED.
6. Routen, welche über eBGP empfangen werden, werden über Routen von iBGP bevorzugt. Dies bedeutet, bird neigt dazu, die Routen zu einem externen autonomen System zu benutzten, anstatt sie weiter in das eigene autonome System zu leiten.
7. Es werden Routen mit der geringsten internen Entfernung zu einem Boundary-Router bevorzugt. Es werden also die Routen bevorzugt, welche von Routern kommen, welche nach außen mit anderen autonomen System verbunden sind.
8. Es wird die Route vom Router mit der niedrigsten Router ID bevorzugt.

Man sollte jedoch beachten, dass die Kriterien Implementationsspezifisch sind. So sind die Kriterien und die Reihenfolge bei FRR beispielsweise teilweise anders.

Wie kann man die Routen-Auswahl beeinflussen?

Path Prepending

Path Prepending ist eine beliebte Taktik, um einen Weg unattraktiver zu machen. Wie man an den Kriterien oben sehen kann, wird die AS Pfad-Länge recht weit oben als Kriterium benutzt. Umso länger der AS-Pfad ist, umso unattraktiver die Route. Möchte man nun nicht, dass eine Route bevorzugt benutzt wird, kann man den AS-Pfad länger machen und damit die Route unattraktiver. In der Praxis hängt man seine eigene AS-Nummer an den Pfad an. Dies bedeutet aber auch, dass Path Prepending erkennbar ist, welches in gut konfigurierten Systemen jedoch kein Problem darstellt. Um Path Prepending in bird durchzuführen, gibt es die Funktion prepend:

bgp_path.prepend(64500);

In diesem Code Abschnitt würde man zum Beispiel die AS Nummer 64500 an den Pfad angehängt (prependen). Dabei gibt das Argument nicht die Anzahl der Prepends, sondern die AS-Nummer, welche angehängt werden soll an. In anderen BGP Implementierungen, kann das Argument jedoch auch die Anzahl angeben! In der Praxis verwendet man ein bis drei Prepends. Danach wird die Route so unattraktiv, dass sie so gut wie nicht mehr verwendet wird. Path Prepending ist also - wenn richtig eingesetzt - ein starkes Mittel, um eine Route global unattraktiver zu machen. Path Prepending geht über das eigene und die benachbarten autonomen Systeme hinaus.

BGP lokale Präferenz

Die lokale Präferenz ist ein sehr starkes Instrument - und könnte beinah als rohe Gewalt bezeichnet werden. Die AS Pfad-Länge oder anderen Kriterien werden nicht mehr überprüft, wenn eine einzige Route zum Ziel eine hohe Präferenz hat. Die lokale Präferenz sollte daher sorgfältig benutzt werden. Eine gute Anwendungsmöglichkeit wäre, wenn man sicherstellen möchte, dass man Routen von einem benachbarten AS direkt zu diesem sendet.

if (bgp_path.len = 1) then
    bgp_local_pref = bgp_local_pref + 700;

Sollte die AS Pfad Länge eins sein, bedeutet dies, dass man direkt eine Route zum Ziel AS hat. Mit diesem Codeblock im Import-Filter kann man also erzwingen, dass diese direkte Route dann benutzt wird.

Warum nicht bgp_path.first = bgp_path.last?

Dies ist einer der Gründe, warum die lokale Präferenz so gefährlich sein kann. Sollte jemand seinen AS-Pfad absichtlich länger machen (Path Prepending), so möchte dieser jemand absichtlich erzielen, dass man eine andere Route wählt. Mit diesem Befehl würde man die Bemühungen wirkungslos machen. Beispielsweise könnte man ein zwei Punkten mit einem AS gepeert sein. Nun ist eine Verbindung kurzweilig instabil und die andere weiterhin stabil. In der Zeit, wo die eine Verbindung instabil ist, soll die andere Verbindung bevorzugt werden - die instabile Verbindung soll allerdings nicht gekappt werden. Daher macht man mit Path Prepending die instabile Verbindung unattraktiver. Da die lokale Präferenz jedoch vor der AS Pfad-Länge überprüft wird, wird das Path Prepending ignoriert und die instabile Verbindung bevorzugt.

Man kann nicht unendlich weit sehen

Ein anderer Grund, warum man lokale Präferenzen vermeiden sollte ist, dass man nur die Verbindung zwischen sich und dem benachbarten AS bewerten kann - beispielsweise wie stabil die Verbindung ist oder welche Latenz vorliegt. Beispiel: Es gibt drei autonome Systeme, welche alle drei miteinander verbunden sind. Die Verbindung zwischen AS A und AS B ist sehr gut. Die Verbindung zwischen AS A und AS C ist zufriendstellend. Die Verbindung zwischen AS B und AS C ist jedoch sehr schlecht. AS A möchte nun AS C erreichen. Die sinnvolle Route wäre, den direkten Weg von AS A zu AS C zu benutzen. Dort wäre die Route zufriedenstellend. AS A hat jedoch für alle Routen von AS B eine hohe lokale Präferenz eingerichtet, da die Verbindung zwischen diesen ASes sehr gut ist. Nach dem Route Selection Algorithmus, wird also die Route über AS B verwendet - AS A -> AS B -> AS C. Da die Verbindung zwischen AS B und AS C jedoch sehr schlecht ist, ist jetzt auch die Verbindung zwischen AS A und AS C sehr schlecht - besser wäre gewesen, wenn AS A eine direkte Verbindung zu AS C aufgebaut hätte, wie es ohne lokale Präferenz gewesen wäre. Dieses Beispiel zeigt, dass man immer nur die Verbindung zu den benachbarten ASes einschätzen kann und nicht deren Verbindung zu anderen Systemen.

Communities

In BGP gibt es Communities. So werden in dn42 beispielsweise BGP Communities verwendet, um Bandbreite, Latenz und Verschlüsselung zu übermitteln. Die Implementierung dieser Communities ist jedoch optional. Des Weiteren können und sollen die Communities von jedem AS auf dem Weg bearbeitet werden - so ist zum Beispiel die höchste Bandbreite von einer Route immer die vom Knoten des Pfades mit der geringsten Bandbreite. Dies wirft zwei Probleme auf: Es kann sein, dass ASes die Communities nicht implementieren und daher wichtige Informationen verloren gehen. Des Weiteren kann es sein, dass die Communities aufgrund einer Fehlkonfiguration falsch bearbeitet werden. Darüber hinaus, würde es sicherheitstechnisch schlecht sein, die lokale Präferenz anhand der Communities festzumachen. Dann könnte ein bösartiger Akteur mithilfe der Communities “behaupten”, er hätte eine sehr gute Verbindung zu allen Systemen. Dies würde dazu führen, dass die lokale Präferenz dafür sorgt, dass jede Route und damit auch der Traffic über den Angreifer geht.

Multiple Exit Discriminator (MED)

Es kann vorkommen, dass zwei autonome Systeme über zwei oder mehr Verbindungen peeren. Ohne MED wird die Route vom Router mit der niedrigsten Router ID ausgewählt. Dies ist kein sinnvolles Auswahlkriterium, jedoch ist es deterministisch (es tritt bei den gleichen Bedingungen immer dasselbe Ergebnis auf). Nun kann man jeder Route ein MED zuweisen. Dabei wird der kleinste MED bevorzugt. Beispiel: Zwei autonome Systeme AS A und AS B sind über zwei Verbindungen miteinander gepeert. Die eine Verbindung ist stabil und die andere instabil. Man möchte die instabile Verbindung jedoch als Backup beibehalten, da sie alternativ Route nicht besser wäre. Wenn man nun die stabile Verbindung bevorzugen möchte, kann man dort eine geringere MED setzen. Dies macht man in bird, indem man bgp_med auf den entsprechenden Wert setzt.

Router ID

Als letztes Vergleichskriterium wird von vielen BGP Implementierungen, darunter auch bird, die Router ID benutzt. Die Router ID wird im Normalfall als IPv4 dargestellt und dient zur eindeutigen Identifizierung eines Routers unter seinen Nachbarn. Dieses Entscheidungskriterium ist zwar deterministisch, jedoch wenig sinnvoll. In bird kann man dieses letzte Entscheidungskriterium dahingehend ändern, dass die Route nicht nach der Router ID, sondern nach der ältesten Route ausgesucht wird. Um dieses alternative Entscheidungskriterium zu benutzten, benutzt man das Statement prefer older on; beim Setup seiner BGP Session. Das Statement wird in protocol bgp geschrieben und gilt dann für die gesamte BGP Session.

Links

• FRR BGP Route Selection
• Bird BGP
• Bird Route Selection
• BGP communities in dn42

The following are criteria in bird:

1. The route with the highest weight is preferred. For this there is the value preference in bird. This is used for example to prefer IGP over EGP - for example Babel over BGP.
2. The route with the highest local preference is selected. This can be influenced in the import filter with the variable bgp_local_pref. The default preference is 100.
3. The route with the shortest AS path is preferred. This is a decisive criterion in all implementations. The path basically specifies (exception: Path Prepending) how many autonomous systems must be traversed to reach the destination.
4. Next, a very rarely used value is checked: the origin. Routes received via IGP are preferred. However, in bird preference is now used.
5. If one has multiple peerings with the same autonomous system, the smallest multiple exit discriminator (MED) is preferred. For example, if one is connected once a dedicated line and once via an IXP, one generally wants to prefer the dedicated line since it does not have to be shared. Therefore routes, which were received over it, get a smaller MED.
6. Routes received over eBGP are preferred over routes received over iBGP. This means, bird tends to use the routes to an external autonomous system instead of forwarding them further into its own autonomous system.
7. Routes with the least internal distance to a boundary router are preferred. Thus, routes coming from routers that are externally connected to other autonomous systems are preferred.
8. The route from the router with the lowest router ID is preferred.

However, one should note that the criteria are implementation specific. For example, the criteria and order are a little bit different for FRR.

How to influence the route selection?

Path Prepending

Path prepending is a popular tactic to make a path less attractive. As you can see from the criteria above, AS path length is used as a criterion quite high up. The longer the AS path, the less attractive the route. Now, if you don’t want a route to be used preferentially, you can make the AS path longer and thus make the route less attractive. In practice, you append your own AS number to the path. However, this also means that Path Prepending is recognizable, which is not a problem in well-configured systems. To perform path prepending in bird, there is the function prepend:

bgp_path.prepend(64500);

In this code section, for example, we would prepend the AS number 64500 to the path. Here, the argument does not specify the number of prepends, but the AS number to be prepended. In other BGP implementations, however, the argument can also specify the number! In practice one uses one to three prepends. After that, the route becomes so unattractive that it is almost never used. Path prepending is therefore - if used correctly - a strong means to make a route globally less attractive. Path prepending goes beyond one’s own and neighboring autonomous systems.

BGP local preference

Local preference is a very powerful tool - and could almost be called brute force. The AS path length or other criteria are no longer checked if a single route to the destination has a high preference. Local preference should therefore be used carefully. A good use of it would be to ensure that routes from a neighboring AS are sent directly to it.

if (bgp_path.len = 1) then
    bgp_local_pref = bgp_local_pref + 700;

If the AS path length is one, it means that one have a direct route to the destination AS. So with this code block in the import filter one can force that this direct route is used then.

Why not bgp_path.first = bgp_path.last?

This is one of the reasons why local preference can be so dangerous. If someone intentionally makes they AS path longer (path prepending), this someone intentionally wants to achieve that you choose another route. With this command you would make the effort ineffective. For example, one could be peered a two points with an AS. Now one connection is temporarily unstable and the other continues to be stable. During the time when one connection is unstable, the other connection should be preferred - but the unstable connection should not be cut. Therefore, Path Prepending makes the unstable connection less attractive. However, since the local preference is checked before the AS path length, Path Prepending is ignored and the unstable connection is preferred.

One cannot see infinitely far

Another reason to avoid local preferences is that you can only evaluate the connection between yourself and the neighboring AS - for example, how stable the connection is or what the latency is. Example: there are three autonomous systems, all three are interconnected to each other. The connection between AS A and AS B is very good. The connection between AS A and AS C is okay. However, the connection between AS B and AS C is very poor. AS A now wants to reach AS C. The reasonable route would be to use the direct route from AS A to AS C. The the connection there would be okay. However, AS A has set up a high local preference for all routes from AS B because the connection between these ASes is very good. So according to the route selection algorithm, the route via AS B is used - AS A -> AS B -> AS C. However, since the connection between AS B and AS C is very bad, now the connection between AS A and AS C is also very bad - it would have been better if AS A had established a direct connection to AS C, as it would have been without local preference. This example shows that one can always only estimate the connection to the neighboring ASes and not their connection to other systems.

Communities

In BGP, there are communities. For example, in dn42, BGP communities are used to communicate bandwidth, latency, and encryption. However, the implementation of these communities is optional. Furthermore, the communities can and should be adjusted by any AS on the path - for example, the highest bandwidth from a route is always that from the node on the path with the lowest bandwidth. This raises two problems: ASes may not implement the communities and therefore important information may be lost. Furthermore, the communities may be processed incorrectly due to misconfiguration. In addition, basing local preference on the communities would be a bad security practice. Then, a malicious actor could use the communities to “claim” to have a very good connection to all systems. This would result in the local preference ensuring that every route, and thus traffic, goes through the attacker.

Multiple Exit Discriminator (MED)

It may happen that two autonomous systems peer over two or more connections. Without MED, the route is selected by the router with the lowest router ID. This is not a useful selection criterion, but it is deterministic (the same result always occurs for the same conditions). Now you can assign a MED to each route. In this case, the smallest MED is preferred. Example: Two autonomous systems AS A and AS B are peered together by two connections. One connection is stable and the other is unstable. However, one would like to keep the unstable connection as a backup since it would not be better alternate route. If you want to prefer the stable connection, you can set a lower MED there. This is done in bird by setting bgp_med to the appropriate value.

Router ID

As a final comparison criterion, the router ID is used by many BGP implementations, including bird. The router ID is normally represented as IPv4 and is used to uniquely identify a router among its neighbors. This decision criterion is deterministic, but not very useful. In bird, one can modify this last decision criterion to select the route based on the oldest route rather than the router ID. To use this alternative decision criterion, use the statement prefer older on; when setting up your BGP session. The statement is written to protocol bgp and then applies to the entire BGP session.

Links

• FRR BGP Route Selection
• Bird BGP
• Bird Route Selection
• BGP communities in dn42

Was ist das Präferenz-Attribut und wofür wird es verwendet?

Das Präferenz-Attribut wird zur Routen-Auswahl verwendet. Es wird noch vor den Protokollspezifischen-Kriterien (beispielsweise Metrik bei Babel, AS-Pfad Länge und BGP Local Pref bei BGP) ausgewertet. Die Route mit der höchsten Präferenz wird bevorzugt. Wenn es zwei Routen mit der gleichen Präferenz gibt, wird entsprechend das protokollspezifische Auswahlverfahren verwendet.

Was ist der Standardwert?

Um nun Routen mit dieser Präferenzen manipulieren zu können, ist es sinnvoll deren Standardwerte zu kennen, jedoch steht dazu aktuell nichts in der Dokumentation. Im Quellcode kann man die Präferenzen jedoch schnell finden. Diese befindet sich in Zeile 748 bis Zeile 755 in der Datei nest/route.h.

Folgendes sind die Standardwerte:

Wie kann man es auslesen?

Sofern man das Präferenz-Attribut nicht im Import-Filter bearbeitet hat, kann man dies in der detaillierten Protokollansicht sehen:

$ birdc show protocol all kioubit
BIRD 2.0.12 ready.
Name       Proto      Table      State  Since         Info
kioubit    BGP        ---        up     2023-06-11    Established   
  BGP state:          Established
[...]
    Local capabilities
      Multiprotocol
        AF announced: ipv6
[...]
    Neighbor capabilities
      Multiprotocol
        AF announced: ipv4 ipv6
[...]
  Channel ipv6
    State:          UP
    Table:          dn42
    Preference:     100
    Input filter:   (unnamed)
    Output filter:  (unnamed)
[...]

Mit der Zeile Preference: 100 sieht man, dass alle importierten IPv6 Routen aus diesem Protokoll (wenn nicht im Filter manipuliert) eine Präferenz von 100 bekommen.

Sollte man die Präferenz nicht für ein Protokoll, sondern für eine bestimmte Route auslesen wollen, kann man dies ganz einfach tun, in dem man den Wert in Runden Klammern ausliest:

$ birdc show route protocol kioubit | head
BIRD 2.0.12 ready.
Table dn42:
fda7:3ae7:e04d::/48  unicast [kioubit 2023-06-11] (100) [AS4242422596i]
    via fe80::ade0 on kioubit
fd23:0:0:f00d::/64   unicast [kioubit 2023-06-11] (100) [AS4242422037i]
    via fe80::ade0 on kioubit
fd66:dca7:46f3::/48  unicast [kioubit 01:32:34.600] (100) [AS4242423772i]
    via fe80::ade0 on kioubit
fd5b:d2c1:2ecc::/48  unicast [kioubit 2023-06-11] (100) [AS4242421832i]
    via fe80::ade0 on kioubit

Hier sieht man beispielsweise, dass alle vier Routen eine Präferenz von 100 haben.

Wann sollte man das Präferenz-Attribut verändern?

Die eigentlichen Präferenz-Attribute sind recht gut gewählt, wenn man jedoch Spezialfälle hat wie zum Beispiel das Mischen der Protokolle, kann es sinnvoll sein, die Präferenz zu verändern - möchte man beispielsweise mit einigen Personen BGP und mit anderen Babel als EGP sprechen und hat auch ein Babel für IGP selber, sollen die EGP Babel Routen natürlich die gleiche Präferenz haben wie die BGP Routen und nur die IGP Babel Routen sollten bevorzugt werden.

Wie verändert man das Präferenz-Attribut?

Dies ist recht einfach, indem man die Präferenz im Import-Filter entsprechend setzt:

filter egp_babel_import {
    preference = 100;
}

Dieser Code orientiert sich am obigen Beispiel.

Dazu sollte man sagen, dass man Babel und BGP nicht einfach als EGP benutzen und mischen sollte, ohne sich vorab entsprechend zu informieren. Dies ist allerdings ein reales Beispiel aus der CRXN/dn42 Interconnection.

Weiteres

Da auch für mich das Thema etwas undurchsichtig ist, habe ich den Blog Eintrag nach neuen Informationen aus der Mailingliste noch einmal neugeschrieben. Die Nachfrage an der Mailingliste kann man im Archiv sehen.

What is the preference attribute and what is it used for?

The preference attribute is used for route selection. It is evaluated before the protocol-specific criteria (for example, metric for Babel, AS path length, and BGP Local Pref for BGP). The route with the highest preference is preferred. If there are two routes with the same preference, the protocol-specific selection procedure is used accordingly.

What is the default value?

In order to be able to manipulate routes with these preferences, it is useful to know their default values, but there is currently nothing about this in the documentation. However, you can quickly find the preferences in the source code. It can be found in line 748 to line 755 in the file nest/route.h.

The following are the default values:

How to read it out?

Unless you have edited the preference attribute in the import filter, you can see it in the detailed log view:

$ birdc show protocol all kioubit
BIRD 2.0.12 ready.
Name       Proto      Table      State  Since         Info
kioubit    BGP        ---        up     2023-06-11    Established   
  BGP state:          Established
[...]
    Local capabilities
      Multiprotocol
        AF announced: ipv6
[...]
    Neighbor capabilities
      Multiprotocol
        AF announced: ipv4 ipv6
[...]
  Channel ipv6
    State:          UP
    Table:          dn42
    Preference:     100
    Input filter:   (unnamed)
    Output filter:  (unnamed)
[...]

With the line Preference: 100 you can see that all imported IPv6 routes from this protocol (if not manipulated in the filter) get a preference of 100.

If you want to read the preference not for a protocol but for a specific route, you can easily do this by reading the value in round brackets:

$ birdc show route protocol kioubit | head
BIRD 2.0.12 ready.
Table dn42:
fda7:3ae7:e04d::/48  unicast [kioubit 2023-06-11] (100) [AS4242422596i]
    via fe80::ade0 on kioubit
fd23:0:0:f00d::/64   unicast [kioubit 2023-06-11] (100) [AS4242422037i]
    via fe80::ade0 on kioubit
fd66:dca7:46f3::/48  unicast [kioubit 01:32:34.600] (100) [AS4242423772i]
    via fe80::ade0 on kioubit
fd5b:d2c1:2ecc::/48  unicast [kioubit 2023-06-11] (100) [AS4242421832i]
    via fe80::ade0 on kioubit

For example, here you can see that all four routes have a preference of 100.

When should you change the preference attribute?

The actual preference attributes are quite well chosen, but if you have special cases like mixing the protocols, it can make sense to change the preference - for example, if you want to talk BGP to some people and Babel to others as EGP and also have a Babel for IGP itself, the EGP Babel routes should of course have the same preference as the BGP routes and only the IGP Babel routes should be preferred.

How to change the preference attribute?

This is quite simple by setting the preference in the import filter accordingly:

filter egp_babel_import {
    preference = 100;
}

This code is based on the example above.

It should be said that one should not simply use Babel and BGP as EGP and mix them without informing oneself accordingly in advance. However, this is a real example from the CRXN/dn42 interconnection.

Further

Since the topic is a bit obscure for me as well, I have rewritten the blog entry after new information from the mailing list. You can see the postings on the mailing list in the archive.

There are various modern solutions for self-meshing networks - unfortunately not all of them are usable (according to my criteria). I have therefore looked at some of these technologies and compared them with each other.

Since a table with a lot of entries quickly becomes ugly, here are a few remarks:

• Tinc fulfills many criteria, but is no longer being actively developed. The main developer still processes pull requests, but is no longer actively working on the code itself due to time constraints. Issues are therefore only sporadically processed or fixed.
• Tinc version 1.0 uses a cryptography system that is not modern. In the new pre-release version, Tinc uses the specially developed SPTPS protocol, which even implements PFS. The development of the pre-release version Tinc 1.1 has been going on for a very long time. Tinc 1.1 is in almost no official package sources. It can be obtained from Alpine Linux via the community repository or from Arch Linux via AUR.
• n2n can only transport data via IPv4. This makes it impossible for IPv6-only nodes to participate in an n2n network.
• n2n also has an Android app. This is itself under a free license, but includes many non-free, privacy-unfriendly components.
• The Tailscale Client itself is free software. However, the actual Tailscale server is proprietary. However, an alternative server implementation is available under the name headscale.
• Tailscale also has an Android app, which is even available in F-Droid. Unfortunately, the app has an anti-feature - it sends debug logs to the developers without consent.
• Zerotier was available for some time under the GPL 3 license. However, the developers have changed to the proprietary BSL license. It allows the use of Zerotier for non-commercial or non-profit purposes.
• Nebula is unfortunately only partially free software. The Linux client is FLOSS and even in the Debian package sources. However, the Android app, which is produced by the same developers, is proprietary.

My criteria are actually quite simple:

• I want full IPv6 support. This is particularly necessary in networks like the dn42, where there are also IPv6-only networks.
• I want full IPv4 support. Although IPv4 is a legacy protocol, it is still used by many - including me - in the dn42.
• The VPN solution should use a fairly secure encryption. This can also include PFS. PFS means that if the long-term key for the connection is compromised, not all old connections can be subsequently decrypted.
• The software should be completely FLOSS. For me, this means preferably under a license that is recognized by both the FSF and the OSI. There are various reasons for this. In this context, it means above all that you can compile it yourself, the security can be audited independently and simple packaging for operating systems is possible.
• I mainly use Debian on my servers. Therefore, the software must be available for Debian. Since I don’t just want to determine the freedom of the software myself, the software must also be in the official package sources.
• An Android app could be added as a bonus. However, this is not necessary, especially in the context of a VIXP, but would be more of a gimmick.

In conclusion, it can be said that only Tinc in the pre-release version fully meets my criteria.