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