> On 3 Aug 2016, at 19:02, Christopher Morrow <[email protected]> > wrote: > doesn't look new to me, no. and 'worse', today someone COULD just (if they > are in the right place and can do bgp packet creation,etc) just tag all of > your announcments to your provider(s) with the local provider version of this > community, blackholing all of your traffic... or they could change the > announcements to withdrawals... or other mean things. the addition of this > blackhole community doesn't change this problem, at all.
You're technically correct to say that there is nothing new about this attack vector but in practice, this draft will end up changing the /24 and /48 default maximum prefix length on all bh-enabled peering sessions to /32 and /128 and will encourage configs to be created to make it easy to propagate BH'd prefixes around the place. Everyone understands that policy can be written to tie this down to be safer and that this will be done on competently managed networks, and that for those networks, this draft will be both safe and useful. All the operators plugging for this draft in the grow wg fall into this category of competence. In reality, a huge number of networks are spaghetti-built on a jumble of incompetently configured devices hacked together by people who don't really know what they're doing. Many network operators are going to screw this sort of config up and will end up shooting themselves and others in the foot. This ignores those network operators who have malicious intent. In their case, this draft adds another blade to their Swiss Army knife, particularly in situations where prefix limits are routinely not used. Stepping back a bit, the ietf has an unfortunate tendency to write off certain categories of operator problem as "out of scope" or "config/implementation error", and this has happened in this case. The problem is, the draft is saying "hey guys, if you bypass a bunch of rcds in the distribution board, you can do some really cool stuff". You sure can, but the person who gets electrocuted in the shower as a result isn't going to care much about whether their shock was out of scope at the protocol level or caused by an implementation problem. Globally scoped damage will have been done either way, whether through malice or incompetence. Using a non transitive community (eg rfc4360) instead of a standard bgp community from the iana well-known range could limit this problem, because that would constrain the scope of any potential damage by enforcing non-transitivity at the bgp stack level. Without at least this safeguard, this draft is imho inadvisable from a global internet stability point of view. Nick _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
