On Tue, Jun 21, 2016 at 8:24 PM, Michel Py <michel@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Christopher Morrow wrote :
> 'Max prefix pressure' care to elaborate a bit more on this?
Let's look at a real-world example : Team Cymru's UTRS.
https://www.cymru.com/jtk/misc/utrs.html
> A participant is only permitted to have up to 25 active route announcements
> through UTRS at a time. Additional routes will be rejected.
I foresee that IXPs and other organizations who would adopt the BLACKHOLE community would put limits just the same as UTRS does. At 25 routes per participant, the mitigation of a DDOS potentially coming from thousands of IP addresses is limited. I totally understand the reasons to permit only 25 (or n) blackholes routes.
this implies that src-route blackholing (discard route + uRPF or similar) is required or targeted for this use-case, which I don't think is a given. Surely, if you want to do that you'd have to accept very, very large prefix sets from your peer(s).
this concern doesn't seem to be a blocker for this draft though...
> 'way too broad' how so?
Because it's "only" one global community.
ok, that doesn't explain it for me though.
> There are many filter knobs to turn in BGP peering
That is the point : there are no knobs to turn with only one community; IMHO, it would be better to have ASN:666 (with ASN being the source AS for the blackhole prefix _or_ the AS of the IXP) and even better to standardize more granularity about the reason for being blackholed.
AS:666 : blackhole
AS:6601 : blackhole because of spam
AS:6602 : blackhole because of ssh brute-force attack
.....
the state today is that three are 'many different communities' which is painful for an operator to manage. It means custom policy for each peer, which is going to (has many times already) bite someone one.
> ok, but not everyone has to peer with your server, and not everyone may agree that
> they want to listen-to/use such a new community in the wider network, right?
Correct, but I realized recently that the only way to have some adoption was to provide more knobs. If you don't block enough prefixes, the blackhole mechanism is not efficient. If you block enough prefixes, people are scared of using it.
that seems contradictory... 'if not enough, bad, if enough, bad'
> at least for me to understand how this is worse than what exists today...
Because some people out there are in the DDOSAAS business; with the standardization of the BLACKHOLE community, some script kiddo could write something that probes to see if it actually works; maybe I'm full of BAAS but there are is a lot of creativity being put into DDOS; if this was to become standard, it could become a new attack vector.
could, could, could... err, nothing definite here that you've pointed out. I think the field of DoS (attacking) is pretty simple, and has been for a very long while. there's no real creativity here. I also don't imagine that this community gets used for the vast majority of dos attacks, but only for those where the potential harm to the IX or the direct participants is a large.
See it the same way as logging in as root : as soon as you have the telnet or ssh port open to the outside, you will have attempts to log in as root. The same reasoning applies to a global blackhole community : compromised systems would to inject a blackhole prefix to see if it works and report to their C&C.
'compromised systmes' meaning a router at the IX? if somoene compromises a router on the IX fabric we've all got much larger problems than 'someone could blackhole something with a community'.
Your idea is good, but it's too broad, too generic.
Michel.
http://arneill-py.sacramento.ca.us/cbbc/