Live data from Hacker News

Who's running all those tiny RPKI servers?

blog.apnic.net

11–19 of 19 posts

Re: Who's running all those tiny RPKI servers?

#11

Earlier quoted context omitted.

There's two kinds of route hijacks. Origin or path based. RPKI addresses who is allowed to originate a prefix. There are other technical changes that need to be implemented to get path validation, this cloud flare blog has a good write up on the issues/solutions. https://blog.cloudflare.com/bgp-route-leak-venezuela/

RPKI addresses both. Route Origin Authorizations (ROAs) enforce which ASes are allowed to originate a prefix. ROAs address origin hijacks, and have been around for longer. Autonomous System Provider Authorizations (ASPAs) enforce which ASes are allowed to be adjacent to each other in an AS_PATH. ASPAs address path hijacks, and were introduced more recently. It used to be that you had to self-host (as in the article)…

Also note that ASPA validation prevents only hijack by peers and customers, not by providers. Due to way how ASPA validation works, providers could always announce to their customers routes with valid-looking AS PATH with hijacked ASN appended at its end.

Re: Who's running all those tiny RPKI servers?

#12

Earlier quoted context omitted.

RPKI addresses both. Route Origin Authorizations (ROAs) enforce which ASes are allowed to originate a prefix. ROAs address origin hijacks, and have been around for longer. Autonomous System Provider Authorizations (ASPAs) enforce which ASes are allowed to be adjacent to each other in an AS_PATH. ASPAs address path hijacks, and were introduced more recently. It used to be that you had to self-host (as in the article)…

Also note that ASPA validation prevents only hijack by peers and customers, not by providers. Due to way how ASPA validation works, providers could always announce to their customers routes with valid-looking AS PATH with hijacked ASN appended at its end.

Trust infrastructures are always like this, it's one reason PGP's "Web of trust" doesn't work at scale.

If you trust Alice then it's not astonishing that Alice can stab you in the back. Most of us can probably manage to pick trustworthy direct friends. But then, what if we're to trust that Alice's friends won't betray us ? That's a lot stickier.

PGP tries to distinguish "Do you trust that Alice is who she says she is?" from "Do you trust that Alice is a good judge of character?" but the latter is largely unknowable and PGP treats it as recursive. You trust Alice, Alice trusted Bob, Bob trusted Caroline and now Caroline's friend Dave stabbed you in the back. How is this Alice's fault somehow?

Re: Who's running all those tiny RPKI servers?

#14

Earlier quoted context omitted.

Also note that ASPA validation prevents only hijack by peers and customers, not by providers. Due to way how ASPA validation works, providers could always announce to their customers routes with valid-looking AS PATH with hijacked ASN appended at its end.

Trust infrastructures are always like this, it's one reason PGP's "Web of trust" doesn't work at scale. If you trust Alice then it's not astonishing that Alice can stab you in the back. Most of us can probably manage to pick trustworthy direct friends. But then, what if we're to trust that Alice's friends won't betray us ? That's a lot stickier. PGP tries to distinguish "Do you trust that Alice is who she says she is…

How is that better or worse than the "I trust everyone my authority trusts" mechanism the authority system uses?

Re: Who's running all those tiny RPKI servers?

#15

Earlier quoted context omitted.

There's two kinds of route hijacks. Origin or path based. RPKI addresses who is allowed to originate a prefix. There are other technical changes that need to be implemented to get path validation, this cloud flare blog has a good write up on the issues/solutions. https://blog.cloudflare.com/bgp-route-leak-venezuela/

RPKI addresses both. Route Origin Authorizations (ROAs) enforce which ASes are allowed to originate a prefix. ROAs address origin hijacks, and have been around for longer. Autonomous System Provider Authorizations (ASPAs) enforce which ASes are allowed to be adjacent to each other in an AS_PATH. ASPAs address path hijacks, and were introduced more recently. It used to be that you had to self-host (as in the article)…

That makes sense, thanks!

Re: Who's running all those tiny RPKI servers?

#16
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 servers.

It is a lame brain scheme to ensure expansion of CT.

The correct architectual security stance is to prevent expensive audit scenario and ensure that the complexity moves from after-the-fact detection (CT) into stronger identity enrollment and authorization (DNSSEC, policy records, key continuity, CA constraints, possibly multi-CA approval).

People making more useless work, yet profit massively.

By doing individual CA with each websites, browser can then ditch the cookie tracking. And privacy restored (it leaks only to that website what you say)

But the $710B data collection industry will have questions.

I absolutely love the idea of auto-creating mTLS/dTLS for each client-website pairing at account creation time.

Ancillary infrastructure crumbles. Backends simplified. Things are faster and simpler for all parties involved (except those evil 3rd party scrapers/sniffer/email-reading scourges.

AI responded as: Benefits:

* eliminates password reuse

* reduces phishing surface

* eliminates many cookie-tracking mechanisms

* allows per-site identity isolation

* improves API/service authentication

the endpoints own the trust relationship; intermediaries provide transport, not identity.

Exactly how a well-designed military or critical-industrial equipment in the field should behave (to prevent inadvert usage of captured/hijacked endpoints)

/end-of-rant

Re: Who's running all those tiny RPKI servers?

#17

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,…

27 years of DNSSEC, you say!

Re: Who's running all those tiny RPKI servers?

#18
post #14

Earlier quoted context omitted.

Trust infrastructures are always like this, it's one reason PGP's "Web of trust" doesn't work at scale. If you trust Alice then it's not astonishing that Alice can stab you in the back. Most of us can probably manage to pick trustworthy direct friends. But then, what if we're to trust that Alice's friends won't betray us ? That's a lot stickier. PGP tries to distinguish "Do you trust that Alice is who she says she is…

How is that better or worse than the "I trust everyone my authority trusts" mechanism the authority system uses?

Having a handful of authorities means we can direct our limited resources at scrutinizing those authorities. Which we do, to great effect. It's not perfect, such a system will never be perfect, but it keeps improving. It's a lot better in 2026 than it was in 2016, and it was a lot better in 2016 than in 2006. In 1996 this is all new and the CAs have basically no idea what they're doing, what's a domain name? Their employees aren't using Tim's toy hypermedia service, it's for nerds.

The resources available to check that Edith's friend Frank's cousin Gerald is trustworthy are zero and when trusting Gerald goes badly, what do we do? "Oh, huh, be more careful"? It's not actionable at all.

Re: Who's running all those tiny RPKI servers?

#19
post #17

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,…

27 years of DNSSEC, you say!

More accurately, running web sites using latest RFCs.
Post reply on HN