Though technically you're right, this kind of attitude is exactly the problem. Everyone should filter all RFC1918 usage on public links, regardless of whether they themselves use is, or their customers use it, or not. To not do such filtering is to be a bad neighbour.
I'm just a home DSL user, and usually a fly on the wall for this mailing list. But I've found it beneficial to make a practical exception to your blanket condemnation of RFC1918 source addresses. I don't think there is much harm to it. The relevant snippet of my rules on my ingress filter is: 1) ... block bad things such as unused or spoofed addrs ... 2) allow icmp from any to any icmptypes 0,3,4,11,12 3) deny ip from 10.0.0.0/8 to any 4) deny ip from 172.16.0.0/12 to any 5) deny ip from 192.168.0.0/16 to any 6) allow tcp from any to any 1024-65535 established 7) ... some other rules ... 8) deny everything else by default Line #2 allows relatively benign incoming ICMP, such as "fragmentation needed", but hopefully blocks the more problematic stuff. I added this exception for a very practical reason. Without it there were many routers, generating ICMP messages using RFC1918 source addresses, whose error messages were important, but that I dropped at the firewall. Interestingly, these messages passed thru MANY intermediate routers that didn't block packets with RFC1918 source addresses. If you take it upon yourself to "filter all RFC1918 usage" from the outside world, you (and your customers) will suffer for it. Because it seems to be established practice out there. Of course I never send packets to the Internet with an RFC1918 address in them.
[ On Sunday, July 16, 2000 at 16:58:52 (-0700), Bohdan Tashchuk wrote: ]
Subject: Re: RFC 1918
Line #2 allows relatively benign incoming ICMP, such as "fragmentation needed", but hopefully blocks the more problematic stuff.
That might be just fine for *you* and anyone *exactly* like you who will *never* use RFC1918 addresses internally yourself. However *everyone* who does use such addresses cannot even allow "harmless ICMP" through as it can suddenly be *far* from harmless. It really really really really is best for *everyone* if *all* RFC1918 addresses, src or dst, *always* gets filtered everywhere possible. The more redundancy here then the better everyone is protected against both their own mistakes as well as those of others. Even better of course is full ingres/egress filtering of spoofed addresses, which of course will obviously block RFC1918 packets along with all other illegal packets. Once you go beyond merely protecting everyone from their mistakes and those of others and you add in the potential malicious uses of such illegal packets (both RFC1918, as well as otherwise spoofed packets), well then the argument becomes overwhelming in favour of full filtering everywhere possbile.
Of course I never send packets to the Internet with an RFC1918 address in them.
Exactly, and so long as anyone who does use such numbers internally is always 100% absolutely perfect in configuring their routers then there's no reason *not* to filter RFC1918 addresses everywhere else to prevent the malicious uses! ;-) Furthermore anyone "accidentally" using any addresses not explicitly assigned to them in publicly accessible places will more quickly learn the error of their ways if all such illegal use is blocked, logged, and reported, at the closest possible point to their borders. -- Greg A. Woods +1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
On Sun, 16 Jul 2000, Bohdan Tashchuk wrote:
The relevant snippet of my rules on my ingress filter is:
1) ... block bad things such as unused or spoofed addrs ... 2) allow icmp from any to any icmptypes 0,3,4,11,12 3) deny ip from 10.0.0.0/8 to any 4) deny ip from 172.16.0.0/12 to any 5) deny ip from 192.168.0.0/16 to any 6) allow tcp from any to any 1024-65535 established 7) ... some other rules ... 8) deny everything else by default
Line #2 allows relatively benign incoming ICMP, such as "fragmentation needed", but hopefully blocks the more problematic stuff.
<SNIP>
If you take it upon yourself to "filter all RFC1918 usage" from the outside world, you (and your customers) will suffer for it. Because it seems to be established practice out there.
The ruleset you use is great for a leaf-node. The problem it can represent on the borders of a larger network is that a lot of nice script kiddies like to spoof their source as RFC1918 space and since ICMP is 8 times out of 10 their payload, using such on the edges exposes the core (and potentially some poor customer of yours on a DS1, etc) to whatever level of hate-and-discontent you're capable of accepting on the borders. --- John Fraizer EnterZone, Inc
Being another fly on the wall who uses RFC 1918 addresses in a corporate networking setting, consider the following: (1) RFC 1918 addresses were never intended for use on the public Internet. (2) People who use RFC 1918 addresses on the public Internet are typically end users who can't spell RFC 1918 much less implement it. (3) Ill-intentioned users will use RFC 1918 addresses in their exploits. (4) RFC 1918 traffic cannot be properly routed once it leaves its originating subnet. (5) Filtering RFC 1918 addresses reflects best practices for managing Internet traffic. Why on earth would anyone object to filtering RFC 1918 traffic? For DSL or other leaf-node users, a list of solutions is easy: fixed IP address, NAT, proxy, etc. The problem is that it's an issue of training, communication, and standards enforcement. ISPs should not be responsible for their downstream's lack of understanding of basic Internet architecture. However, if an ISP wants to keep its customers from endless ignorance and frustration, it would not be a bad idea to offer resources by which users can gain a basic operational understanding that would at least keep them from making simple but costly mistakes. But we can't have it both ways. We can't get educated end users by endlessly telling them RTFM. We can't coerce them to have a clue. But we also can't simply shut them off. In doing so, we invite the backlash of frustration and its companion effects on revenue and reputation. And we can't fix it for them. They have to come to the conclusion that it's appropriate to seek information and act on it. They have to recognize that there are rules of engagement for building IT resources and connecting them to the Internet, and that many of these rules are non-negotiable. The filtering of RFC 1918 addresses is a simple, logical, and effective example. John Fraizer wrote:
<snip> The ruleset you use is great for a leaf-node. The problem it can represent on the borders of a larger network is that a lot of nice script kiddies like to spoof their source as RFC1918 space and since ICMP is 8 times out of 10 their payload, using such on the edges exposes the core (and potentially some poor customer of yours on a DS1, etc) to whatever level of hate-and-discontent you're capable of accepting on the borders.
--- John Fraizer EnterZone, Inc </snip>
-- -------------------------------------------------------------------------- Stephen Kowalchuk skowalchuk@diamonex.com Diamonex, Incorporated
"Stephen" == Stephen Kowalchuk <skowalchuk@diamonex.com> writes:
Stephen> Why on earth would anyone object to filtering RFC 1918 Stephen> traffic? I think this thread is beginning to get a bit long, but... Imagine that you inherit a network where RFC1918 addresses are used on most or all backbone links. Because it's reasonably difficult to get real addresses from ARIN for a company starting from scratch, this is perfectly plausible (need customers to justify address space -> need network to get customers -> must build network before address space is acquired). But, like most things that are intended to be temporary, these private addresses on backbone links are likely to become semi-permanent. Now everybody who does a traceroute to or from one of your customers sees an RFC1918 address or two. "Don't build it like that in the first place" is not a very usefull answer -- sometimes there is no choice. Migrating the addresses of the whole backbone could take some time, so what to do in the meantime? Do you start filtering in the core of your network? Do you start making the 7507s in your transit path process switch each packet in the 30Mb of traffic that they're forwarding? Sometimes filtering them out is just impractical untill you can buy a Juniper M40 ;) -w -- Will Waites \________ ww@shadowfax.styx.org\____________________________ Idiosyntactix Ministry of Research and Development\
Imagine that you inherit a network where RFC1918 addresses are used on most or all backbone links.
Imagine you inherit two of them, and they're both using 10.1.x.x. That's the kind of trouble that end-users have as well. When their networks are running 10.1.1.x and they get ICMP messages from remote networks with that address, all kinds of problems can occur. I noticed over the weekend I got a couple of ICMP Redirect messages from 1918 space. Lovely. Somebody doesn't understand how Redirect works, which is typical of the crap that comes in from 1918 space. Filtering 1918 isn't just good practice for most of the leaves, it's mandatory in a lot of cases. No traffic should ever appear on the WAN link using that address (that would violate the spec, right?) so anything that does is bad traffic by definition. Filtered. Easy. When ISPs choose to mark their packets with Internet-illegal addresses, they are contributing to these problems. Sorry, but you're not supposed to be using these addresses anyway.
Because it's reasonably difficult to get real addresses from ARIN
ARIN is absolutely the root cause of the 1918 problem. They're the principle driver behind the NAT market by extension as well. If it weren't for their qualification rules, the Internet would work a helluva lot better. Imagine that. Management decides to limit address consumption, so the rats start duplicating addresses, building protocol gateways and crufting other hacks to get around the restriction. Who'd have thunk such a thing would happen. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
"Eric" == Eric A Hall <ehall@ehsco.com> writes:
>> Imagine that you inherit a network where RFC1918 addresses are >> used on most or all backbone links. Eric> Imagine you inherit two of them, and they're both using Eric> 10.1.x.x. That's the kind of trouble that end-users have as Eric> well. When their networks are running 10.1.1.x and they get Eric> ICMP messages from remote networks with that address, all Eric> kinds of problems can occur. Agreed. Eric> When ISPs choose to mark their packets with Internet-illegal Eric> addresses, they are contributing to these problems. Sorry, Eric> but you're not supposed to be using these addresses anyway. >> Because it's reasonably difficult to get real addresses from >> ARIN Eric> ARIN is absolutely the root cause of the 1918 Eric> problem. They're the principle driver behind the NAT market Eric> by extension as well. If it weren't for their qualification Eric> rules, the Internet would work a helluva lot better. Looking at the BGP tables, I see lots of holes in the address space. A particularly big one is almost a quarter of IPv4 space -- 65.0.0.0 - 126.255.255.255, which is listed as reserved by ARIN. Since IPv6 can be seen on the horizon, maybe they should start allocating some of this, and stop forcing people into problematic situations like using RFC1918 addresses in the core by artificially creating scarcity? And what about 5.0.0.0/8 and 7/8 and 11/8 etc. that are all listed as allocated but are not used. Due to the scarcity of this public resource, should there not be some sort of "use it or lose it" policy? Cheers, -w -- Will Waites \________ ww@shadowfax.styx.org\____________________________ Idiosyntactix Ministry of Research and Development\
been there done that ;~} While I was at Networkers one of the sessions I attended briefly touched upon Cisco's new hack for dealing with this it was a combination of MPLS and NAT applied at the border router(s) to solve the overlap problem. I have been looking for more information because I do have some overlap problems "Eric A. Hall" wrote:
Imagine that you inherit a network where RFC1918 addresses are used on most or all backbone links.
Imagine you inherit two of them, and they're both using 10.1.x.x. That's the kind of trouble that end-users have as well. When their networks are running 10.1.1.x and they get ICMP messages from remote networks with that address, all kinds of problems can occur.
I noticed over the weekend I got a couple of ICMP Redirect messages from 1918 space. Lovely. Somebody doesn't understand how Redirect works, which is typical of the crap that comes in from 1918 space.
Filtering 1918 isn't just good practice for most of the leaves, it's mandatory in a lot of cases. No traffic should ever appear on the WAN link using that address (that would violate the spec, right?) so anything that does is bad traffic by definition. Filtered. Easy.
When ISPs choose to mark their packets with Internet-illegal addresses, they are contributing to these problems. Sorry, but you're not supposed to be using these addresses anyway.
Because it's reasonably difficult to get real addresses from ARIN
ARIN is absolutely the root cause of the 1918 problem. They're the principle driver behind the NAT market by extension as well. If it weren't for their qualification rules, the Internet would work a helluva lot better.
Imagine that. Management decides to limit address consumption, so the rats start duplicating addresses, building protocol gateways and crufting other hacks to get around the restriction. Who'd have thunk such a thing would happen.
-- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
Public IP address allocation from ARIN is a totally different matter. My point is that filtering RFC 1918 addresses at your network's borders is the right thing to do for a number of reasons. IMHO using RFC 1918 addresses on your backbone routers (or any other public device) for anything other than emergency or truly temporary use is a recipe for disaster. My $0.02. ww@shadowfax.styx.org wrote: <snip>
Imagine that you inherit a network where RFC1918 addresses are used ... </snip>
-- -------------------------------------------------------------------------- Stephen Kowalchuk skowalchuk@diamonex.com Diamonex, Incorporated --------------------------------------------------------------------------
"Stephen" == Stephen Kowalchuk <skowalchuk@diamonex.com> writes:
Stephen> Public IP address allocation from ARIN is a totally Stephen> different matter. If people need assign addresses to things, they're going to do it. If certain bureaucracies prevent them from doing it the correct way, they'll do it the incorrect way, which is what we're discussing here. Stephen> My point is that filtering RFC 1918 Stephen> addresses at your network's borders is the right thing to Stephen> do for a number of reasons. Which is good in theory, but sometimes is not possible. Up untill very recently a router did not exist that could actually do this when a significant amount of traffic is being pushed through it. Cheers, -w -- Will Waites \________ ww@shadowfax.styx.org\____________________________ Idiosyntactix Ministry of Research and Development\
participants (7)
-
Bohdan Tashchuk -
Eric A. Hall -
John Fraizer -
Scott McGrath -
Stephen Kowalchuk -
woods＠weird.com -
ww＠shadowfax.styx.org