North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
RE: private ip addresses from ISP
- From: Andrew Kirch
- Date: Tue May 23 09:34:41 2006
> -----Original Message-----
> From: firstname.lastname@example.org [mailto:email@example.com] On Behalf
> Robert Bonomi
> Sent: Tuesday, May 23, 2006 9:22 AM
> To: firstname.lastname@example.org
> Cc: email@example.com
> Subject: Re: private ip addresses from ISP
> > Date: Tue, 23 May 2006 03:33:34 -0400
> > From: Richard A Steenbergen <firstname.lastname@example.org>
> > To: email@example.com
> > 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
> > > > arriving at
> > > > your interface from your ISP?
> > ...
> > > Sorry to dig this up from last week but I have to strongly
> > > point #3.
> > > >From RFC 1918
> > > Because private addresses have no global meaning, routing
> > > about private networks shall not be propagated on
> > > links, and packets with private source or destination addresses
> > > should not be forwarded across such links. Routers in networks
> > > using private address space, especially those of Internet
> > > 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
> > > should be dropped as a matter of course, along with any routing
> > > advertisements for RFC 1918 space(From #1). ISP's who leak 1918
> > > into my network piss me off, and get irate phone calls for their
> > > trouble.
> > The section you quoted from RFC1918 specifically addresses routes,
> > 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
> addresses -- 'TTL exceeded' for example -- that one should
> allow across network boundaries.
> > If you're receiving RFC1918 *routes* from anyone, you need
> > thwack them over the head with a cluebat a couple of times until the
> > filling oozes out. If you're receiving RFC1918 sourced packets, for
> > 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_
> that attack, for example. (This provider has inbound source-filtering
> their Internet 'gateway' routers, but *not* on their customer-facing
> (either inbound or outbound.)
> It's even more comical when the NSP uses RFC1918 space internally, and
> *not* filter those source addresses from their customers.
> > There are semi-legitimate
> > packets with those sources addresses to float around the Internet,
> > they don't hurt anything.
> I guess you don't mind paying for transit of packets that
> have any legitimate purpose on your network.
> Some of us, on the other hand, _do_ object.
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.