Hacker News Reader

Comment by akerl_ | Hacker News Reader

Who would be in charge of the moderation?

This very article describes the closest thing to that: NANOG is a collection of network operators, and they communicate with each other about the overall state and coordination of "the internet", which realistically is just "the total set of a lot of network operators agreeing to connect to each other".

Domain registration and DNS have much more centralization because there exists a root entity for the entire (public) system and an owner of each TLD: if an entity wants to remove example.com from existence, they can go to the .com operator and attempt to compel them to do that. For IP routing, you're talking about BGP between a vast number of different entities. By design, traffic can route a variety of ways between each point.

View on HN

I had a conversation with a friend about this, and the outcome was the idea that BGP could be extended with functionality for this case. There needs to be a way to brand "negative" traffic or routes advertised with some sort of reputation system. In the event of a DDoS attack coming from an AS, you could have intra-AS weight for any given AS such that if an AS reports malicious traffic from a route, it's given a lower weight and traffic is less likely to route to that AS in favor of a less specific prefix. This would encourage any given AS to act in desirable ways, as their actions (or actions coming from within them, e.g. a customer of theirs being the source of a DoS attack) would have consequences.

How would that work in practice? If I compromise a pile of IoT devices running on Comcast users' networks, and use them to launch and attack, all Comcast users on their subnet get marked as uncool? And if we're marking them as "bad", doesn't that mean all of their BGP peers mark them as uncool and then the weights for their prefix are lower but still even, so routing still ends up the same?

The only way they'd be impacted would be if some networks didn't implement your bad-actor-prefix-weight-mod, and then we'd just be penalizing the people who don't use your system along with the attackers, since we'd be routing the bad traffic via their networks.

You can see the impact of this kind of thinking in RBLs and blocklists - try to send email via your residential connection and you probably won't be able to.

You might be interested in the DOTS working group at the IETF.

https://datatracker.ietf.org/wg/dots/charter/

Yes that’s true, most of the work and moderation is done via mailing lists (like in Linux dev or with IETF/RFCs) but when we’re talking about the infrastructure I would expect something more efficient. Sure someone must notice it and report it, but I don’t get why it takes so long. And just to avoid misunderstandings I’m not talking about censorship, but actual WTF situations as this one described in the post where it’s obvious what is happening with Bitcanal.

How do you decide whether the bad BGP announcement was an accident or malicious?

When someone accidentally announces an incorrect prefix, they're pretty up-front about it, and try to correct it as soon as possible. It's not something you really see that often either, as you don't change the prefixes you announce very often. Really only when you acquire new IP space. Otherwise, the router config is largely set-and-forget as long as the peerings are up.

So if someone does fat-finger a prefix announcement, it's followed by an email to the IX mailing lists and transit providers with an apology and a quick fix.

It starts to become apparent who made an honest mistake here and there and who's acting maliciously.

When the announcer doesn't immediately retract it in embarrassment, continues to announce it, the RIPE/APNIC/ARIN WHOIS data for the block continues to show ownership info other than the announcer, and the announcer doesn't produce a legitimate business relationship and LOA for why they should be announcing that "new" /18. It's usually pretty obvious.

How many hours / days / weeks do you need to give the announcer to produce all that evidence, before considering the action as malicious and undoing the announcement?

Proving a business relationship sounds like a multi-day endeavor, whereas you typically want to undo the damage ASAP.

a few days, maximum. If you're $SMALLISP and you have a /22 of space, and your upstream is $MEDIUMISP, you give a LOA (letter of authorization) to $MEDIUMISP allowing them to announce your prefix to their peers and upstreams. If $MEDIUMISP can't produce that LOA on demand and the ARIN/RIPE/WHOIS/APNIC/AFRINIC whois data, email/admin/technical contacts for the /22 owned by $SMALLISP don't respond with "yup that's our block and we are allowing $MEDIUMISP to announce it", something highly fishy is going on.

If you think a requirement to forge a paper document is going to stop a spammer who hijacks IP space...

One more count of fraud don’t mean a thing to these criminal operations.

I would not rely on it at all. At a certain point a bgp hijacker has to have some sort of physical interconnection to get to upstreams or an IX. Either equipment colocated at or near an IX, a transport circuit, something. Showing a forged LOA to somebody's colocation process is something that can be helpful in getting them to physically power off/disconnect a customer's equipment for abuse.

Reply on news.ycombinator.com