Who's Running All Those Tiny RPKI Servers?
I investigated the long tail of small, independent RPKI publication servers operating alongside the major Regional Internet Registries. These tiny servers, run by cloud providers, ISPs, and even hobbyists, manage a surprisingly diverse set of IP prefixes for reasons ranging from operational control to simple curiosity. While they cover a small fraction of global address space, their existence highlights the decentralized nature of Internet security and the varied motivations behind maintaining cryptographic trust.
One potential reason a spam operator would run their own RPKI server is that having an independent publication server adds an extra step in the takedown chain, creating a layer of operational friction for abuse reporters.
- ipdashc
Cool stuff. Though I've never quite understood how RPKI solves route hijacks. The article says it validates that you're allowed to announce a given prefix outright, but I thought the idea behind a BGP hijack was that you just say you have a good route towards a given prefix, and traffic flows through you as a result?
- egberts1
17.6% of assigned BGP-able IP address space are assigned but not actively broadcasting BGP packets???
(Deep-breath in, warning: rant)
This makes for a very problematic of continual hijacking AS link pathways between two hosts, notably between two countries.
BGPsec is well designed but remains largely unused (due to high-speed carrier-grade router's unwillingness to update firmware for new packet datagrams within BGP, not to mention requiring the addition of expensive de-crypt/re-crypte chipsets.
Interim SW-based solutions like BGP-ROA and BGP-ASPA are like HTTPS CAs, need to do PGP-style "trusting your friends' trusting other friends', ad naseum.
Alice trust Bob who trust Charles who trust Dave but Dave stabs Alice in the back. Um, no.
27 years of hosting my websites and DNSSec, but I can't prevent an island of Antigua to hijack my very own AS ... without all engaging in BGPSec. Unless all participate in BGPSec.
Crappy workaround such as the self-hosting of a RPKI API server is the HTTPS CA for that BGP AS hijack problem and it's still a wild, wild Internet.
Even then, that boondoggle infrastructure (Google/CloudFlare/DigiCert/LetsEncrypt) of mass Certificate Transparency (CT) monitoring station is trying to do fingerprint imprints of all the CAs' hash values for all websites; that design approach is time-sensitive and is a glaring weakness for not using dTLS/mTLS (where web servers ALSO authenticates its clients as well as the standard TLS client also authenticates web serv […]