On Fri, Jun 24, 2016 at 11:10 PM, Michel Py <michel@xxxxxxxxxxxxxxxxxxxxxxxxxxx> 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"
"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"
"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