private ip addresses from ISP

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

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

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

While we're on the topic, perhaps I should ask for some best practices
(where 'best' equals one for every listserv member) on the use of RFC 1918
addresses within a network provider's infrastructure.

We use private addresses for some stub routes, as well as our cable modems.
Should we aggressively move away from private stub networks? And for the
second, should we specifically limit access to those cable modem IPs to just
our management network ? Right now any of customers could do an SNMP sweep
and identify them all, but I don't really care that much about that, or
should I?

And yes, I do have RFC 1918 filters on our outbound traffic. =)

Frank