On Wed, 22 Jun 2016 00:24:19 +0000 Michel Py <michel@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote: > Let's look at a real-world example : Team Cymru's UTRS. > https://www.cymru.com/jtk/misc/utrs.html Hello. :-) For those that hadn't heard, I've recently left Team Cymru just a few weeks ago, but can obviously speak to that project that is still running as I did briefly at the security track at NANOG 67. > 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. That was admittedly an arbitrary limit. One potential peer had said they would need the max to be at least a few hundred. This person was from a DDoS mitigation company unsurprisingly. > 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 ..... UTRS had started with community tag ending in :666, but then at the suggestion of discussion on the list, we opted to set the default to local_asn:0 where local_asn is the asn of the announcing network and the 0 being the default value, but with potential future use of it to signify a remote peer with which action is directed. I don't think it would it was likely I would have gotten around to implementing anything like that soon, but it at least prepared us for that potential flexibility. John