On Tue, Jun 21, 2016 at 8:24 PM, Michel Py <
michel(_at_)arneill-py(_dot_)sacramento(_dot_)ca(_dot_)us> wrote:
Christopher Morrow wrote :
'Max prefix pressure' care to elaborate a bit more on this?
Let's look at a real-world example : Team Cymru's UTRS.
https://www.cymru.com/jtk/misc/utrs.html
A participant is only permitted to have up to 25 active route
announcements
through UTRS at a time. Additional routes will be rejected.
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.
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).
this concern doesn't seem to be a blocker for this draft though...
'way too broad' how so?
Because it's "only" one global community.
ok, that doesn't explain it for me though.
There are many filter knobs to turn in BGP peering
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
.....
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.
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?
Correct, but I realized recently that the only way to have some adoption
was to provide more knobs. If you don't block enough prefixes, the
blackhole mechanism is not efficient. If you block enough prefixes, people
are scared of using it.
that seems contradictory... 'if not enough, bad, if enough, bad'
at least for me to understand how this is worse than what exists today...
Because some people out there are in the DDOSAAS business; with the
standardization of the BLACKHOLE community, some script kiddo could write
something that probes to see if it actually works; maybe I'm full of BAAS
but there are is a lot of creativity being put into DDOS; if this was to
become standard, it could become a new attack vector.
could, could, could... err, nothing definite here that you've pointed out.
I think the field of DoS (attacking) is pretty simple, and has been for a
very long while. there's no real creativity here. I also don't imagine that
this community gets used for the vast majority of dos attacks, but only for
those where the potential harm to the IX or the direct participants is a
large.
See it the same way as logging in as root : as soon as you have the telnet
or ssh port open to the outside, you will have attempts to log in as root.
The same reasoning applies to a global blackhole community : compromised
systems would to inject a blackhole prefix to see if it works and report to
their C&C.
'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'.
Your idea is good, but it's too broad, too generic.
Michel.
http://arneill-py.sacramento.ca.us/cbbc/