ietf
[Top] [All Lists]

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

2016-06-25 20:53:15
On Fri, Jun 24, 2016 at 11:10 PM, Michel Py <
michel(_at_)arneill-py(_dot_)sacramento(_dot_)ca(_dot_)us> wrote:

Michel Py wrote :
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.

Christopher Morrow wrote :
​ 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).

The number of prefixes and the use of uRPF are orthogonal. BCP38 would be
nice, OTOH I understand why it's not widely deployed.


​sure, it's the particular holistic goal represented...  One usecase for
'send routes which you prefer to see blackholed remotely' is:
  "I am seeing 100gbps of traffic to this /32, please stop filling up my
interconnect"

Another is:
  "All of these things are bad, I would like you to filter them before they
appear on my network"

I don't think the use-case envisioned for the community is the second one.

Further there's no reason that a route-server operator needs to REQUIRE the
use of any particular community. They could, very well, choose to say:
"Yes, I know there's that well known community, but we like 0:2525 so we're
just going to keep on using that, thanks!"

That seems fine, to me. I'm sure the RS participants in question can either
follow along or pressure the RS operator to use the 'well known' option.
(or both!)

this concern doesn't seem to be a blocker for this draft though...

That's the difference between a draft that will become a deployed standard
and one that will eventually be deprecated. Acceptance / adoption in the
real world.


​not everyone has to use it? so... not really a blocker.
not everyone uses (or adheres to the wishes of) NO-EXPORT either.​

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

It means custom policy for each peer-group, which is what operators do and
want.


​toma-toe, tomA-toe ... (group/peer/etc)​

Here's the thing, speaking as an operator of a not-small network... I don't
really want to manage 1800 different outbound policies and their associated
knobs. I really do want to manage a minimal number, where 'minimal number'
is ~3.

Having to remember / configure each peer which provides 'blackhole
community' features has a different community to send is bonkers. it's also
prone to errors, oversharing and all sorts of other problems...



​'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'.​

You should see what "IX fabric" means, in many places. I rest my case.


​I've seen quite a few, thanks!
-chris​