Also, Linode is planning some server reboots over the next week or so. We will try to give advance notice and keep downtime to a minimum.
Update: Everything seems to have quieted down. Many many thanks to NotSanguine for jumping in and lending his expertise to help identify and isolate where things were borked.
Indications are that a bad BGP (Border Gateway Protocol) route was published causing a relatively small AS (Autonomous System) to have all traffic to/from a large fraction of the internet attempt to go through its routers.
(Score: 2) by NotSanguine on Monday June 24 2019, @09:58PM (2 children)
Note, that I said "something akin to rPKI" not rPKI.
Cryptographic signatures can be useful *without* centralization.
Especially since verification needs to be done *between* peers/upstream/downstream providers, with signatures being confirmed to be valid by each peer, then updated again before being forwarded to the next set of peers. Which does not require anything top-down or centralized, just verification and trust between peers.
Why don't you write a protocol spec using RFC 7353 [ietf.org] that can be conformed with RFC 8212 rather than playing "gotcha" with me?
I'm sure we'll all appreciate your hard work. I look forward to reading your Internet Draft when you're done.
No, no, you're not thinking; you're just being logical. --Niels Bohr
(Score: 2) by NPC-131072 on Tuesday June 25 2019, @12:33AM (1 child)
Noted.
Wasn't playing "gotcha" but we've gone from origin to path validation. [ietf.org] Giving RIRs (or LIRs) the technical ability to revoke certs will surely make their politicization inevitable?
(Score: 2) by NotSanguine on Tuesday June 25 2019, @03:05AM
Fair enough.
But I haven't *gone* anywhere. I think you misunderstand me.
Given that it behooves peers, as well as upstream/downstream providers to play it straight with each other, *especially* when it comes to BGP, given that they *need* each other to carry/forward their network traffic as expeditiously and efficiently as possible.
There's no profit in refusing to verify a BGP update signature via the public key provided by a peer. Once such signature is verified, the receiving peer *should* verify that the routes make sense WRT routes currently being advertised by other peers (whose signatures they *also* verify). Once such a BGP update has been validated, the receiving peer needs to *re-sign* the update with its own private key, with the public key associated with it having been securely shared with *its* peers, then forward that update to its peers.
The next hop should do the same thing. Ad inifinitum.
Given that these peers have a vested interest in maintaining those relationships, it's unclear to me why they would, unless it's warranted (e.g., malicious route updates, repeated errors in route updates, etc.), revoke the public key of a peer.
What "political" advantage would *anyone* get by doing so? All you'll end up doing is cutting off your nose to spite your face.
No, no, you're not thinking; you're just being logical. --Niels Bohr