RE: private ip addresses from ISP
-----Original Message----- 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
From RFC 1918 Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise
point #3. 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
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:
-----Original Message----- 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
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?
...
From RFC 1918 Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise
Sorry to dig this up from last week but I have to strongly disagree with point #3. 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. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
RAS> Date: Tue, 23 May 2006 03:33:34 -0400 RAS> From: Richard A Steenbergen RAS> If you're receiving RFC1918 sourced packets #include "flamewars/urpf.h" #include "flamewars/pmtud.h" Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
On May 23, 2006, at 3:33 AM, Richard A Steenbergen wrote:
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? :) -- TTFN, patrick
On Tue, May 23, 2006 at 12:23:54PM -0400, Patrick W. Gilmore wrote:
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? :)
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. :) -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
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
On May 23, 2006, at 1:14 PM, Richard A Steenbergen wrote: [...]
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. :)
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. -- TTFN, patrick
participants (6)
-
Andrew Kirch
-
Edward B. DREGER
-
Hyunseog Ryu
-
Patrick W. Gilmore
-
Richard A Steenbergen
-
sthaugļ¼ nethelp.no