address spoofing

Sun Apr 25 13:12:59 UTC 1999

Phil Howard wrote:
> 
> Greg A. Woods wrote:
> 
> > > So are you making a case to allow RFC1918 source addresses out into the
> > > network?
> >
> > Huh?  No, I thought I was saying very much the opposite!  I don't want
> > my upstream provider to use RFC1918 on inter-router links, but they do
> > anyway.  I'd like them to filter those addresses too, but they won't.
> 
> I do agree they should be filtered out.
> 
> At what point should we draw the line and say who can, and who cannot,
> use RFC1918 addresses on links?  My first thought would be any link over
> which traffic from more than one AS transits, or between AS's, should
> always be fully routable.  Any better ideas?

My take on this is the line is at the edge of a single, end customer. In
other words, a company which buys IP service from an ISP may use RFC
1918 addresses internally. An ISP should NOT use private address space
in their own network for any equipment, with the exception of their
administrative or management functions, provided those functions are
restricted in scope to their own use. There should be no gear in the
path from an end customer to peering points which use private address
space.

The reason I arrive at this conclusion is for the sake of the end user.
The purpose, in my opinion, of the private address space described in
RFC 1918 is to allow users to build large networks without consuming
public address space. The goal was to provide someplace for private
networks to go that'd be unique to themselves, provided they didn't talk
to another private end user. Now what happens when a company has already
used 10.x.x.x and built a large network, and uses NAT or proxies at
their border, but their upstream ISP decides to also use 10.x.x.x for
everything? There is real potential for conflict.

What I find most annoying about my upstream using private address space
for their own use is it takes away my ability to use that address space
as an end customer, and could have required me to renumber to ensure
there were no conflicts.

-- 
-----------------------------------------------------------------
Daniel Senie                                        dts at senie.com
Amaranth Networks Inc.            http://www.amaranthnetworks.com