Nick Hilliard wrote :
I would have said the opposite, i.e. that any traffic tagged with this prefix
is dropped via e.g. null0
or martian mechanisms / etc. But it definitely needs to be defined because at
the moment it's ambiguous.
Ambiguity is fine when it's your own network, but not fine when you're
defining something with global scope.
Totally agree. Default behavior on vendor "C" router : if the prefix comes with
NO-EXPORT, there is nothing to do so that it is not announced out of the local
AS. Prefix not announced to eBGP peers because of well-known community. That's
what well-known communities are, right ? DEFAULT behavior is coded-in by the
vendor.
Same as BLACKHOLE : well-known community, router should drop it by default, and
here is the major concern : DEFAULT behavior. If BLACKHOLE as currently
proposed is handled the same way NO-EXPORT is, having it enabled by default is
a danger.
As said in my initial reaction : too broad.
Job Snijders wrote :
The word 'source' does not appear in the draft. In my reading of section 3.1
it is obvious destination based blackholing,
but I welcome a suggestion to reword a sentence in the introduction to
include the phrase 'destination based blackholing'.
The destination-based was not obvious to me on the first read. Besides, my
concerns are not what the intent of a draft is, but what people will do with it
if implemented. A reword will definitely make it more palatable.
As of what people will do with it, what tells you that your intent of
blackholing the destination will not be perverted as blackholing the source ?
There are commercial services out there already that provide source-based BGP
blackhole feeds. My personal one happens to be on the wild side, but again
what's the difference ?
joel jaeggli wrote:
It should be an inherent property that what is being blackholed is traffic
bound for the prefix that the community is attached to is it not?
Yes, but how do you make that happen ? There are some people out there that
have implemented uRPF. What you suggest is a standardized codepoint to kill the
victim in order to protect the infrastructure. I understand that, sometimes
necessary. However, if you are the prefix under attack, there is much better :
feed a source-based blackhole to your upstreams, which kills the aggressor
instead of killing you.
Source based RTBH requires some explicit coordination between the parties
using it.
How so ? if you trust that the party you announce your blackhole to will check
that it is indeed your prefix, you are being unrealistic. Especially lately
with the thing known as "PA leasing", people do announce prefixes that are not
coming from the ASN they are supposed to, and it's not prefix hijacking. I'm
not saying it's right, because it's basically multi-homing a PA, but it does
happen and it's not going to get better.
heasley wrote :
Why wouldn't you want to propogate BH routes? If you want to BH the traffic,
then let it be dumped closer to the
source. You might accidentally make things exciting for yourself, but it
seems like desirable behavior to me.
Indeed, and this is a lot more true when the blackhole targets the source. The
further it is propagated, the better.
Christopher Morrow wrote :
I like this game... but, "Why would the document specify that this is
either/or src/dest blackholing?"
maybe I'm expecting consenting adults to still be playing at the end of the
day...
Because it would make it less controversial ?
Michel.