Jahowering@aol.com wrote:
The DOS attack should be a real concern when using RFC 1918. A distributed) smurf attack, or one of it's derivatives, can cause the icmp echo replies to be sent to that src. address. Since the attackers just use blocks and blocks of spoofed addresses, you could become the sourced address victim. Of course, ingress and egress rfc 1918 filtering will prevent this...it's just something else to think about...
Well, those routes not being globally distributed mitigates that danger. The reverse argument could actually be made- I'm unlikely to see any DoS backscatter directed at the RFC1918 addresses, while the publics will always see it. I forgot one of the most important reasons we are migrating away from this practice. We do source address filtering via RPF verification at the edge, but it allows the /30 to leak because there is a valid route for it internally. Meaning that deliberately spoofed packets can still escape our network, and allowing just one per client is still too many. The better answer to our DoS victim, of course, is an ACL for every hop from the border at the border;that will be implemented as we complete the purge of RFC1918. Steve- the pain of renumbering is simply not worth it... take it from someone who's been there and don't use 'em. Backbone links might be easier to do than clients, but in the end you WILL end up renumbering when it breaks something a client needs. Save yourself the hassle and do it right from the start.