diff options
Diffstat (limited to '_posts/2024-03-17-further-learnings-from-running-my-as.md')
| -rw-r--r-- | _posts/2024-03-17-further-learnings-from-running-my-as.md | 93 |
1 files changed, 93 insertions, 0 deletions
diff --git a/_posts/2024-03-17-further-learnings-from-running-my-as.md b/_posts/2024-03-17-further-learnings-from-running-my-as.md new file mode 100644 index 0000000..25ffaf6 --- /dev/null +++ b/_posts/2024-03-17-further-learnings-from-running-my-as.md @@ -0,0 +1,93 @@ +--- +layout: post +title: Further learnings from running my AS +date: 2024-03-17 14:42 +0100 +lang: en +categories: ["tech"] +--- + +You can think of this as the second part to +[Running my own AS]({% post_url 2023-08-18-networking-adventure-my-own-ipv6-prefix-and-as %}). + +So, it's been about 6 months since I started running my own AS. Recently, I +tried to dive into RPKI/ROA validation. I had quite some head scratching trying +to understand some of this stuff, getting confused over obsolete documentation, +and so on. This post might get updated to reflect my ongoing learning. +I'll probably also throw the bird config into my [Ansible +repo](https://git.uvok.de/ansible/) at a later time (yadda yadda work is +exhausting, I need the weekend to relax, yadda yadda). + +I've gotten a second prefix, this time paying for it, at a provider which offers +RPKI for their prefixes. This is not strictly necessary for me, but it… kinda +"feels better", and gives me the chance to experiment with stuff. Or so I +thought, turns out I get a "management GUI" where I can enter the prefix, an AS +number, and that's it, I don't see what's going on in the background. (The +actual signing; I can see the verification results on +[bgp.tools](https://bgp.tools/)). Oh well, dealing with crypto myself would +probably only have lead to more head-scratching. + +So, first off: Why do I need ROA/RPKI at all, in the BGP landscape? Basically +to prevent foreign AS announcing prefixes they don't own. This happened in the +past, e.g. for censoring YouTube in authoritarian states. Where does the +information what one can announce come from? This happens via the +Regional Internet Registries (e.g. RIPE). Their databases contain all +the AS and IP prefixes, with the IP prefix entries containing information about +which AS (singular?) is allowed to announce them. RPKI is… uh… the information +which prefixes should origin from which AS, cryptographically signed. Entered by +the prefix owners (I think). I lack the detailed knowledge here. "SecureBGP" is +another way to solve the problem of AS announcing prefixes they don't own, but +that's a different protocol, and I haven't looked into it at all. + +So, to use or check this information, you need an additional piece of software, +the validator. There are probably roughly a dozen around, some of them stopped +being maintained. I'm not even gonna try listing them here, the info will be +outdated at some later point anyway. The basic operation seems to be "grab the +RIR database entry dumps, scan them, and provide a way to send requests for +validation", using the "RTR protocol" (RPKI to router protocol). + +In my case, bird2 provides an rpki protocol block, and using the function +`roa_check`, the imported routes are checked against the RPKI database. There +are basically three states, VALID, INVALID and UNKNOWN (the latter meaning: no +matching entry, validator is down?). Then you can decide what to do with +"faulty" routes. I went with keeping them at first, tagging them with a +community, sending all these routes to the bgp.tools route collector (for a nice +analysis), and setting up a second table which goes into the kernel. The +"incoming" and the "used" table are connected via the pipe protocol, and this is +where I do the filtering, i.e. reject the invalid routes. + +Aside: On can *also* export the RPKI/ROA info in a compatible format to a single +file and use that as input for bird, but I don't know how reloading works in +that case. I think you have to do an explicit `birdc configure`, meaning all the +routes you currently have get flushed. With rpki protocol and the right +configuration (`import table` and `rpki reload`), this happens "automagically" +(?), without losing the current routes. + +Some things I stumbled upon when setting stuff up: The software +[StayRTR](https://github.com/bgp/stayrtr) (which has a very cute logo) uses a +pre-build database ("VRR export"?) when started up without any further config, +fetching it from the internet. Startup is nearly instant. When I started setting +up [Fort Validator](https://github.com/NICMx/FORT-validator), I was confused +because "it's not working". Well, I had to tune the default config, so the log +is emitted on info level, and there I could see the software was grabbing all +the RIR database data. Which took some time. After that, it started working as +well. + +Also, if you use an internet search machine for this topic, you'll see slides +that StayRTR and rpki-client are used together. This made me a bit mad, because +I didn't see why. I was using StayRTR + bird2 just fine together. Turns out, +StayRTR needs the aforementioned VRR exports. It grabs these from the internet +by default, but you can just as well build this yourself using rpki-client. +Apparently. Haven't tried that. + +The "general advice" seems to be to run at least two different RPKI validators, +using different software, and ideally in geographically diverse locations. I +opted to ignore the geographical advice, this is a hobby, I don't wanna rent VPS +all over the world. + +Anyway, that's it for this time. + +Futher info: +- [Philip Smith's Internet Development Site / bgp4all](https://bgp4all.com/pfs/hints/rpki) +- [DN42 wiki](https://dn42.eu/howto/Bird2#route-origin-authorization), scroll + down for RPKI example configuration. + |