RE: private ip addresses from ISP

Mailman List Mirror (Read Only)
1

From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf

Of

David Schwartz
Sent: Wednesday, May 17, 2006 1:37 PM
To: nanog@nanog.org
Subject: RE: private ip addresses from ISP

> Our router is running BGP and connecting to our
> upstream provider with /30 network. Our log reveals
> that there are private IP addresses reaching our
> router's interface that is facing our upstream ISP.
> How could this be possible? Should upstream ISP be
> blocking private IP address according to standard
> configuration? Could the packet be stripped and IP be
> converted somehow during the transition? It happens in
> many Tier-1 ISP though !
>
> Thank you for your information

  Do you mean:

  1) You are seeing BGP routes for addresses inside private space?

  2) You are seeing packets with destination IPs inside private

space

arriving at your interface from your ISP?

  3) You are seeing packets with source IPs inside private space
arriving at
your interface from your ISP?

  If 1, feel free to filter them. You ISP probably uses them
internally and
is leaking them to you. Feel free to complain if you want.

  If 2, make sure you aren't advertising routes into RFC1918 space

to

your
ISP. If not, you should definitely ask them what's up.

  If 3, that's normal. These are packets your ISP received that

are

addressed
to you and the ISP is leaving to you the decision of whether to accept
them
or not. Feel free to filter them out if you wish. (It won't break

anything

that's not already broken.)

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.

Andrew

2

In reality, from what I see, most large ISP doesn't care about RFC1918.
I've been dealing with this issue for a while.
Not all of them, because I didn't deal with all of them.
But some of them has strange policy for ACL, because it has large impact on router platform CPU utilization.
Strictly some ISP doesn't allow to put ACL for more than 24 hours including RFC1918 ip address space originated traffic.
So I'm doing it from our core router to block those traffic, and fun to watch the counters increasing so rapidly. ^.^

For an example,
hryu@chc-core-r1> show firewall filter XXX-in
Filter: XXX-in
Counters:
Name Bytes Packets
XXX-in-default 430738360735883 743436641099
XXX-in-rfc1918-10 12742937908 41900221
XXX-in-loopback 785367140 2678266
XXX-in-dhcp-default 36982506 413978
XXX-in-rfc1918-172-16 1240646548 13026411
XXX-in-test-net 44318 621
XXX-in-rfc1918-192-168 1806857741 17309861
XXX-in-reserved-e-class 0 0
ospf-deny 14135 35
h323 8785570 186042
XXX-in-microsoft 305199975828 5751955784
ms-exclude 424428929 696688
on-fire 173190029170 5970455314

I'm wondering whether this is really about router platform issue, and they want their customer including smaller ISPs to bill more because of these junk traffic.

Hyun

Andrew Kirch wrote:

3

> 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. 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. There are semi-legitimate reasons for
packets with those sources addresses to float around the Internet, and
they don't hurt anything. If you really can't stand seeing an RFC1918
sourced packet over the Internet it is more of a personality problem than
a networking problem, so a good shrink is probably going to be more useful
than a good firewall.

4

Date: Tue, 23 May 2006 03:33:34 -0400
From: Richard A Steenbergen

If you're receiving RFC1918 sourced packets

#include "flamewars/urpf.h"
#include "flamewars/pmtud.h"

Eddy

5

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 know it was late when you wrote that, RAS, but from the _very_first_sentence_:

and packets with private source or destination addresses
   should not be forwarded across such links

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. There are semi-legitimate reasons for
packets with those sources addresses to float around the Internet, and
they don't hurt anything. If you really can't stand seeing an RFC1918
sourced packet over the Internet it is more of a personality problem than
a networking problem, so a good shrink is probably going to be more useful
than a good firewall.

Incorrect. Not to mention Just Plain Wrong.

Please read BCP38 again. (For the first time? :slight_smile:

6

I know it was late when you wrote that, RAS, but from the
_very_first_sentence_:

Er yeah I meant to say it says nothing about filtering 1918 packets.

Please read BCP38 again. (For the first time? :slight_smile:

Clearly allowing anyone to inject large quantities of spoofed packets into
the Internet is Bad (tm), no one is arguing that. First of all note that I
was talking about how you deal with packets you receive, not packets you
send. Hate to bust out the old "be conservative in what you send and
liberal in what you receive" line, but in this case it is true. There are
legitimate uses for RFC1918 sourced packets (as has been pointed out many
times, for example, ICMP responses from people who want/need their routers
to not source packets from publicly routed space).

Filtering every last 1918 sourced packet you receive because it might have
a DoS is like filtering all ICMP because people can ping flood. If you
want to rate limit it, that is reasonable. If you want to restrict it to
ICMP responses only, that is also reasonable. If on the other hand you are
determined to filter every 1918 sourced packets between AS boundries
(including ttl exceed, mtu exceed, and dest unreachable) because an RFC
told you you "should", you are actually doing your customers a disservice.

If you are an end-user network or don't transit other people's packets and
you want to do yourself a disservice then by all means filter 1918 sourced
packets until you are blue in the face. If on the other hand you do handle
other people's packets, I would encourage you to fully consider the
ramifications before you go out and apply those filters. This is why k00ks
who can only cite RFC's instead of think for themselves and large networks
tend to be a bad mix. :slight_smile:

7

Filtering every last 1918 sourced packet you receive because it might have
a DoS is like filtering all ICMP because people can ping flood. If you
want to rate limit it, that is reasonable. If you want to restrict it to
ICMP responses only, that is also reasonable. If on the other hand you are
determined to filter every 1918 sourced packets between AS boundries
(including ttl exceed, mtu exceed, and dest unreachable) because an RFC
told you you "should", you are actually doing your customers a disservice.

Well, some of us happen to disagree. I have been very happy to see that
both at my previous and at my present employer (large SPs by Norwegian
standards), all 1918 traffic is filtered at the borders. We have never
had any trouble from customers because of this, and we certainly intend
to keep the filters. And yes, we have had these filters in place for
several years...

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

8

[...]

Filtering every last 1918 sourced packet you receive because it might have
a DoS is like filtering all ICMP because people can ping flood. If you
want to rate limit it, that is reasonable. If you want to restrict it to
ICMP responses only, that is also reasonable. If on the other hand you are
determined to filter every 1918 sourced packets between AS boundries
(including ttl exceed, mtu exceed, and dest unreachable) because an RFC
told you you "should", you are actually doing your customers a disservice.

If you are an end-user network or don't transit other people's packets and
you want to do yourself a disservice then by all means filter 1918 sourced
packets until you are blue in the face. If on the other hand you do handle
other people's packets, I would encourage you to fully consider the
ramifications before you go out and apply those filters. This is why k00ks
who can only cite RFC's instead of think for themselves and large networks
tend to be a bad mix. :slight_smile:

No one is arguing that you should ruin your business because an RFC told you to. (At least no one reasonable.) However, in your first post you said:

If you're receiving RFC1918 sourced packets, for the
most part you really shouldn't care. There are semi-legitimate reasons for
packets with those sources addresses to float around the Internet, and
they don't hurt anything.

I disagree. As do many people. You -should- care when people do bad things. And passing bogon-source packets between ASes is a Bad Thing.

You suggest thwacking people "over the head with a cluebat" when they send you 1918 prefixes. Is that really a problem? It's easy to filter (as everyone should be doing already), and doesn't really 'break' anything. So why the vehemence? Because it is a Bad Thing. And the Internet doesn't work if everyone does Bad Things. As a result, you get upset when people do Bad Things.

But, as you point out, sometimes customers are stupid. So sometimes you have to do things that upset you. You get paid for connectivity, and customers don't understand why certain actions hurt the Internet.

For instance, I get pissed when someone sends 256 /24s instead of one /16. But that doesn't mean I suggest filtering all 256 /24s. Customers would get pissed if they can't reach their fav pr0n server in that /16. Similarly, if someone sends you 1918-sourced packets, you may have to accept them to keep your customers happy. But you should care. And you should be upset.

Telling people they need to see a shrink for trying to keep the 'Net clean is not the correct response.