On Wed, 22 Jun 2016 00:24:19 +0000
Michel Py <michel(_at_)arneill-py(_dot_)sacramento(_dot_)ca(_dot_)us> 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