Christopher Morrow wrote: > first noting that it'd be helpful if you have concerns to suggestions > that you send text that might be used to address them. Playing 'bring me > a rock' is not fun for anyone. "bring me a rock" was not intended. Also, email is a terrible medium for communication (mea culpa) :-( > As to the denial of service wording removal/change, i thought the change > was actually positive because it removed a bit of ambiguity "if a > network offering blackholing is traversed" only really applies if that > network: > 1) hears the prefix with the community > 2) is configured to do something with that announcement > > To back up a bit in the conversation I viewed the draft/document as > doing two specific things: > 1) reducing operational complexity between consenting bgp speaking adults > 2) letting operations staff decide how/where/what to do with a prefix > seen from their peer(s). which is fine and we all agree on this. What we don't agree on is whether creating this particular weapon will cause more problems than it solves. > I think a community today is used (many actually) to signal requested > treatment of a prefix across an AS boundary (rfc1998 for example), > operators on both sides of the peering decide what to add to a prefix on > exit, and what to do with the additions on receipt. I expect peers to be > consenting adults and to not shoot themselves in the foot... that isn't the problem, though. The problems will be caused by other people either injecting prefixes into their own rtbhs and accidentally leaking them to upstreams or else deliberately staging hijacks. Other people have argued that there's no new attack vector here, just a different outcome from the same attack vector (i.e. dropping instead of redirecting traffic). There's a case to be made with this argument, but OTOH, prefix hijacking is rampant and there are lots of situations where people do not or cannot feasibly implement prefix filtering. This is what bothers me. > I would expect this proposed community to be used along with adding > no-export on receipt at the peer, because sending the community more > broadly isn't as helpful. Yeah, not doing this is going to be a common misconfiguration. I can't decide on the overall aims of the draft. It would be hugely convenient to have a community like this, no doubt about it, but the transitive nature of the community and humanity's utter inability not to screw things up means that problems are going to happen. I'd be happier if the text were tightened up to be much more specific about what the semantics of the term "blackhole", and then we could do an IETF and write any problems off as operational misconfiguration, but even still, that niggling feeling that this is overall a bad idea is not going away. Summary: conflicted. Nick