Add post about AS again

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.
+