FROP: Routing-daemon vergelijking
Ergens dit jaar besloot ik dat het krom was: ik praat al jaren met anderen over IP-ruimte, BGP-beleid en RPKI, maar had zelf nog nooit een eigen ASN aangevraagd. Dus kwam er een eigen stukje internet: AS219265. Om zelf te blijven snappen wat er speelt, in plaats van er alleen over te horen. Dezelfde reden als achter mijn eigen mailserver: het kan makkelijker via een grote partij, maar dan mis je precies de dingen die het interessant maken.
FROP draait op mijn server bij ColoClue (met OpenBGPD), een /48 IPv6-reeks en een eigen /24 (om er bij te horen). De hele configuratie komt uit NetBox en wordt met Jinja2 naar een werkende bgpd.conf gerenderd (thanks Claude😉).
Waar ik heen wilde
Toen het tijd werd om het peering-beleid op de website vast te leggen, wilde ik niet zomaar "iedereen mag peeren" opschrijven. Het beleid werd:
- minimaal 100 geadverteerde prefixes, tenzij ik je persoonlijk ken; om alleen serieuze netwerken te hoeven onderhouden
- verplicht IRR, RPKI (invalid = weigeren) en ASPA; om BGP-hijacking de kop te smoren
- wederzijdse bescherming: minimaal RTBH en bij voorkeur BGP Flowspec; om de continuïteit in het geval van een DDoS te borgen.
Dat laatste punt bleek een interessantst rabbit hole in het project.
Het probleem: geloven is niet hetzelfde als weten
Een peer kan prima zeggen dat ze RTBH of Flowspec ondersteunen. Maar hoe verifieer je dat, zonder toegang tot hun router? Een paar iteraties later kwam ik uit op een truc die zonder poortscans of vantage points bij de peer werkt:
Stuur een ping vanaf een test IP-adres (een los adres uit de /48 of /24) naar het interface-adres van de neighbor. Zet daarna de RTBH-community (RFC 7999, 65535:666) of een Flowspec-drop-regel op datzelfde adres. Komt de ping niet meer terug? Dan moet de ICMP-reply van de neighbor (die net zo goed via hun routing-tabel moet) op hun kant zijn weggevallen. Geen externe probe nodig: het antwoordpakket verklikt of ze RTBH ondersteunen.
Voor Flowspec zit er een addertje onder het gras: een flowspec-regel wordt vaak als apart ACL in het forwarding-pad geïnstalleerd, en het is niet gegarandeerd dat zelf-gegenereerd verkeer van de peer's eigen router daar ook doorheen moet. Oplossing: als de eerste test geen verschil laat zien, een echte host áchter de peer opzoeken (via .1/.254 van hun eerst-ontvangen prefixes) en de test daarmee herhalen. Dat is gegarandeerd forwarding-plane-verkeer, geen self-reply-gok meer. Dit moet ik nog in praktijk testen, hoeveel bruikbare resultaten er uit komen.
Het resultaat is verify_protection.py: een generiek, herbruikbaar script met IPv4/IPv6-ondersteuning, een preflight-check (draait dit systeem OpenBGPD überhaupt?), en output in checklist-vorm — zodat een [FAIL]-regel zonder verdere uitleg naar de technische contactpersoon van de peer te kopiëren is. Er is zelfs een route-server-variant: op een gedeeld peering-VLAN (zoals FrysIX) kun je een neighbor testen zonder er zelf bilateraal mee te peren, puur via de RTBH-community richting de route server en een directe ping over de gedeelde LAN.
Zijstap: plaatjes adhv Akvorado
Tussendoor heb ik Akvorado opgezet. Akvorado is een flow-collector met dashboard: hij vangt NetFlow/sFlow op en tekent er meteen mooie Sankey-diagrammen van, "hier komt mijn verkeer vandaan, hier gaat het heen".
Het aardige stukje: voor "bij welk AS hoort dit IP-adres" leunt Akvorado standaard niet op publieke whois- of GeoIP-database (er is wel een geoip-plugin), maar op BMP (BGP Monitoring Protocol, RFC 7854). De router hoort daarmee passief zijn eigen, actuele BGP-RIB naar Akvorado te sturen. Daarmee is de AS-herkomst in de grafieken is precies het pad dat de router zelf voor dat verkeer gebruikt, inclusief alle eigen filtering en voorkeuren (route-maps), niet een generieke lookup uit een database ergens anders.
Software-vergelijking: flowspec en RPKI/ASPA
Om de Flowspec-poot van het beleid goed te implementeren, moest ik uitzoeken hoe volwassen de open-source BGP-daemons daar eigenlijk in zijn; en dat viel tegen. Ik heb niet alleen documentatie gelezen, maar in het geval van GoBGP en OpenBGPd ook de source laten doorzoeken: geen enkele regel code die de RFC 8955-validatieprocedure implementeert, nul treffers op de kernterm "best match" in de repository's.
| OpenBGPD | FRR | GoBGP | BIRD | Juniper | Nokia | Arista | |
|---|---|---|---|---|---|---|---|
| IRR | ✅ extern (bgpq4) | ✅ extern (bgpq4) | ✅ extern | ✅ extern | ✅ extern (bgpq4) | ✅ extern (bgpq4) | ✅ extern |
| RPKI ROV | ✅ ingebouwde RTR-client | ✅ losse package + module-flag | ✅ ingebouwde RTR-client | ✅ | ✅ | ✅ | ✅ |
| ASPA | ✅ RTR v2 | ❌ | ❌ alleen los research-project | ✅ sinds 2.16 (2024) | ❌ | ❓(wel extern: RAVEN-monitor) | ❌ |
| BMP | ❌ | ✅ RFC 7854 v3 (-M bmp) |
✅ | ✅ sinds 2.14 (2023) | ✅ sinds 13.3, ook post-policy | ✅ | ✅ pre/post-policy |
| Flowspec ontvangen | ❌ (alleen versturen) | ✅ (alleen ontvangen) | ✅ | ✅ | ✅ | ✅ | ✅ |
| Flowspec validatie (RFC 8955 §6) | ❌ (feature request open, #151) | ❌ bevestigd afwezig | ❌ zelf geverifieerd in source | ✅ RFC 8955 §6 + RFC 9117 | ✅ (uitzetbaar) | ✅ | ❌ bevestigd afwezig |
| Flowspec effectueren | ❌ | ⚠️ via pbrd/Netfilter, niet elke build | ⚠️ via zebra mogelijk | ⚠️ externe tool (bird-flowspec-daemon of Flow) | ✅ hardware (TCAM) | ✅ hardware | ✅ hardware (TCAM) |
⚠️ = werkt, met reële beperkingen. Bronnen: eigen man-pagina's, source van GoBGP, en documentatie van de betreffende projecten/vendors.* |
|||||||
| ¹ Cumulus Linux draait FRR als routing-engine — features volgen dus in principe FRR, maar het is niet bevestigd welke daarvan NVIDIA daadwerkelijk blootlegt. Dat verklaart mogelijk waarom flowspec bij Cumulus officieel afwezig is, ook al kan FRR zelf het wel ontvangen: "kan de engine het" en "legt de vendor het bloot" zijn twee verschillende vragen. |
De rode draad: op RFC 8955-validatie en ASPA na lopen de software-routers merkbaar achter op wat Juniper en Nokia al langer bieden. OpenBGPD en BIRD trekken dat het dichtst; FRR en GoBGP duidelijk minder.
Wat er nog moet gebeuren
Dit hele traject test alleen of een peer ons beschermt. De andere richting — zelf RTBH-communities en Flowspec-regels die we van peers ontvangen ook netjes toepassen — staat nog open, net als de daadwerkelijke uitrol: de canary opzetten, de generieke announce flowspec live zetten, en de eerste echte run tegen een neighbor draaien.
Wordt vervolgd.
