Re: private ip addresses from ISP

[Daniel Senie <dts () senie com>]

At 09:22 AM 5/23/2006, Robert Bonomi wrote:

> > Date: Tue, 23 May 2006 03:33:34 -0400
> > From: Richard A Steenbergen <ras () e-gerbil net>
> > To: nanog () nanog 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.

Really? You really want TTL-E messages with RFC1918 source addr? Even 
if they're used as part of a denial of service attack? Even though 
you can't tell where they actually came from?

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

So you really don't want ANY packets with RFC 1918 source addresses 
then, not even ICMP TTL-E messages, since they could be used in a 
malicious fashion, and you would not be able to determine the true origin.


> It's even more comical when the NSP uses RFC1918 space internally, and does
> *not* filter those source addresses from their customers.

You mean like Comcast using Cisco routers in their head-ends and 
having the 10/8 address show up in traceroutes and so forth? Not sure 
to what degree it's the NSP's fault vs. the router vendors', but yes.


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

Along with this goes the usual flamewar over RFC 2827, ingress 
filtering (of which URPF is a subset implementation).


> Some of us, on the other hand, _do_ object.

And some of us pay for bandwidth, care about getting congestion 
problems from useless traffic, etc. Perhaps it makes the case a lot 
clearer for selling "better than equal" service to the highest bidder 
if your network is overrun with undesired traffic.