IP backbone numbering/naming

Jahowering at aol.com Jahowering at aol.com
Sat Nov 16 08:34:10 UTC 2002

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


In a message dated 11/16/2002 12:19:36 AM Eastern Standard Time, 
mike at rockynet.com writes:

> haesu at towardex.com wrote:
> >You could also use RFC1918 numbers for your point-to-point /30 
> >aggregation blocks with the customers.. But.. since that would have 
> >effect on customer's premise equipment, it would be better to give 
> >them globally unique space as well, who knows if your customer comes 
> >back and yells at you for not being able to get to his router's serial 
> >interface IP.
> >
> This practice was implemented here in the early days, before I came 
> along. There have been almost no requests to change by clients, and 
> very, very few who even noticed/cared enough to ask why.
> But as more VPNs are deployed, I've seen this break some 
> implementations. So for two reasons we've begun the (large) task of 
> renumbering all the /30 ptp links either public or unnumbered:
> 1) Ensures all clients who decide to implement VPN don't run into 
> frustration because of this practice. We want to encourage better 
> security practices, and VPN can be an integral part of that.
> 2) The script kiddies won't mistakenly assume that we're not doing 
> source address filtering. I'm sure that seeing a private address in 
> traceroute probably makes you a more desirable target in certain circles.
> There is only one case where I would recommend using a private address 
> on a public link. We have a client periodically attacked, and in some 
> cases the attackers have simultaneously attacked our own infrastructure. 
> They now have only one path to them here, and every hop past the border 
> is RFC1918.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20021116/b9238386/attachment.html>

More information about the NANOG mailing list