3 ms·

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

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.

akerl_ 8y ago
How do you decide whether the bad BGP announcement was an accident or malicious?
- xraystyle 8y ago
  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.
- walrus01 8y ago
  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.
  - ge0rg 8y ago
    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.
    - walrus01 8y ago
      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.
      - tatersolid 8y ago
        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.
        walrus01 8y ago
        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.

akerl_ 8y ago

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

xraystyle 8y ago
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.
walrus01 8y ago
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.
- ge0rg 8y ago
  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.
  - walrus01 8y ago
    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.
    - tatersolid 8y ago
      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.
      - walrus01 8y ago
        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.