private ip addresses from ISP

> -----Original Message-----
> From: owner-nanogmerit.edu [mailto:owner-nanogmerit.edu] On Behalf
Of
> Robert Bonomi
> Sent: Tuesday, May 23, 2006 9:22 AM
> To: nanognanog.org
> Cc: davidswebmaster.com
> Subject: Re: private ip addresses from ISP
> 
> 
> > Date: Tue, 23 May 2006 03:33:34 -0400
> > From: Richard A Steenbergen <rase-gerbil.net>
> > To: nanognanog.org
> > Subject: Re: private ip addresses from ISP
> >
> >
> > On Mon, May 22, 2006 at 04:30:37PM -0400, Andrew
Kirch wrote:
> > >
> > > > 	3) You are seeing packets with source
IPs inside private
space
> > > > arriving at
> > > > your interface from your ISP?
> > ...
> > > Sorry to dig this up from last week but I
have to strongly
disagree
> with
> > > point #3.
> > > >From RFC 1918
> > >    Because private addresses have no global
meaning, routing
> information
> > >    about private networks shall not be
propagated on
inter-enterprise
> > >    links, and packets with private source or
destination addresses
> > >    should not be forwarded across such links.
Routers in networks
not
> > >    using private address space, especially
those of Internet
service
> > >    providers, are expected to be configured
to reject (filter out)
> > >    routing information about private
networks.
> > >
> > > The ISP shouldn't be "leaving"
anything to the end-user, these
packets
> > > should be dropped as a matter of course,
along with any routing
> > > advertisements for RFC 1918 space(From #1).
ISP's who leak 1918
space
> > > into my network piss me off, and get irate
phone calls for their
> > > trouble.
> >
> > The section you quoted from RFC1918 specifically
addresses routes,
not
> > packets.
> 
> I quote, from the material cited above:
>       "  ..., and packets with private source or
destination addresses
>        should not be forwarded across such links.  ... 
"
> 
> There are some  types of packets that can legitimately
have RFC1918
source
> addresses --  'TTL exceeded' for example -- that one
should
legitimately
> allow across network boundaries.
> >          If you're receiving RFC1918 *routes*
from anyone, you need
to
> > thwack them over the head with a cluebat a couple
of times until the
> cluey
> > filling oozes out. If you're receiving RFC1918
sourced packets, for
the
> > most part you really shouldn't care.
> 
> *I* care.
> 
> When those packets contain 'malicious' content, for
example.
> 
> When the provider =cannot= tell me which of
_their_own_customers_
> originated
> that attack, for example.  (This provider has inbound
source-filtering
on
> their Internet 'gateway' routers, but *not* on their
customer-facing
> equipment
> (either inbound or outbound.)
> 
> It's even more comical when the NSP uses RFC1918 space
internally, and
> does
> *not* filter those source addresses from their
customers.
> 
> >                                      There are
semi-legitimate
reasons
> for
> > packets with those sources addresses to float
around the Internet,
and
> > they don't hurt anything.
> 
> I guess you don't mind paying for transit of packets
that
> _cannot_possibly_
> have any legitimate purpose on your network.
> 
> Some of us, on the other hand, _do_ object.
> 
> YMMV
> 
Well said, I think that Robert has done a phenomenal job of
summing up
my point.  I don't want this trash on my network.  The
pertinent RFC
says it shouldn't be entering my network from *your*
network (for
varying values of your).  I don't buy the argue that the
end user should
decide what traffic they do and don't want when the RFC
states
unequivocally that the traffic shouldn't be there. Even
reasonably large
networks are often run by people with no appreciable
networking
experience, MCSE, MCP MCP+I etc.  This is a simple fact of
life.
 
Andrew