address spoofing

Greg A. Woods woods at
Sat Apr 24 00:09:20 UTC 1999

[ On Friday, April 23, 1999 at 16:15:30 (-0700), John Leong wrote: ]
> Subject: Re: address spoofing
> > Furthermore, whether the RFC [1918] says so or not, I'm going to block
> > these packets at *my* border routers, because:
> Curious as to the cost (added latency) in doing RFC 1918 source address
> filtering on all packets in the context of cost-benfit analysis.

Well, there's no question as to the benefit if you actually use any of
those networks internally -- I for one never want to see a packet on a
public interface that appears to have come from one of my management
networks, and conversely I'm going to be extremely careful not to let
packets slip out from my management networks onto a public network,
especially in the case of internal misconfigurations.

It seems to me that if you're going to filter for one or two of your own
internal management networks then there's zero added cost to simply
increase the prefix to match the entire larger RFC 1918 group since your
private management networks are obviously going to be a part of *some*
RFC 1918 prefix, right!

It also seems that if you're going to filter for one prefix then you
probably won't lose much additional latency or router cycles if filter
the whole works, not to mention that you'll have additional piece of
mind in knowing that if someone internally starts using one of the other
RFC 1918 prefixes, or the test net, or whatever, you'll still be
protecting them too.

In fact I run filters on each server, with separate physical interfaces
for public and internal "management" traffic; as well as on the routers
with interfaces on the border in order to protect things even if some
wire gets plugged into the wrong port.  Such configurations are far less
forgiving of sloppy configuration, of course, but that's the idea. 

							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at>      <robohack!woods>
Planix, Inc. <woods at>; Secrets of the Weird <woods at>

More information about the NANOG mailing list