ietf
[Top] [All Lists]

Re: Last Call: <draft-ietf-grow-blackholing-00.txt> (BLACKHOLE BGP Community for Blackholing) to Proposed Standard

2016-06-21 11:34:07
On Mon, Jun 20, 2016 at 11:39 PM, Michel Py <
michel(_at_)arneill-py(_dot_)sacramento(_dot_)ca(_dot_)us> wrote:

I have to point out that, although it looks like a move in the right
direction, the newly created BLACKHOLE community is likely to meet severe
max-prefixes resistance. It is way too broad.


'​Max prefix pressure'​ care to elaborate a bit more on this? I seems, to
me, that the community is not really 'max prefix' relevant, as much as 'if
the IXP (or whomever) sends more prefixes, I should be aware and take
appropriate actions.

​'way too broad'​ how so?

I did read the draft, and I do understand it is targeted at IXPs; the
skeptical part in me is suggesting that the max-prefixes limit will limit
the efficiency of this method. In order for this to be efficient to
mitigate a DDOS attack, it would require the prefix limit for the very
generic BLACKHOLE community to be in the tens of thousands. I just don't
see this happening in the real world. A BGP community with global
significance will face significant challenges. I don't see operators
trusting this community.


​perhaps not all operators, but perhaps some will, right? not everyone
trusts/abides-by 'no-export' either.​ This is really about 'what value
should we all use?" not about accepting the routes, or really even what to
do if you see this community on a route? You could just QoS the particular
packets in the community tagged prefix not drop traffic to it...

Extreme caution should be used when purposefully propagating IP prefixes
tagged with the BLACKHOLE BGP community outside the local routing domain.

This is the part that I find out-of-touch with reality. Extreme caution
should be used not to announce RFC1918 prefixes, and not to announce the
entire Internet routing table. It happens all the time.

This draft creates a DDOS vector of its own : an attacker with good BGP
feeds to their upstreams could use the well-known community to craft a new
DDOS attack by injecting the target prefixe(s). Unlike the NO_ADVERTISE or
NO_EXPORT communities, this is a global DDOS bait.

As the operator of a large BGP Blackhole feed (1), the first requests that
came out of the beta-testers were asking for more granularity. My BGP
blackhole feed is over 100K prefixes; it works for me and my beta-tester
buddies, but it won't work for everyone.


​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?

There are many filter knobs to turn in BGP peering, this particular
document just talks about agreeing on 'what communty value should we all
use here?' instead of: "hey Job uses X, I use Y, Sam uses Z... now how do I
sort out my policy such that I send the right commnuities to the right
peer??"​

I oppose this draft on the grounds that it creates more opportunities for
DDOS attacks than it solves.


​you'll have to provide more detail I think... at least for me to
understand how this is worse than what exists today... Essentially an IXP
would have to choose to support ​this community and all peers would have to
agree to accept/use the prefixes so marked.



Michel.

(1) http://arneill-py.sacramento.ca.us/cbbc/