private RFC-1918 addresses on public routers
Usually, when a "private" address hits the bogon filters, a quiet note to the perpetrator gets the problem fixed promptly. This time, the fellow seems to want to argue. Since he's been on this list for awhile (posted here about 8 months ago), perhaps he's educable. His characterization isn't what I remember from the previous discussion(s). Moreover, with the recent emphasis on filtering bogus source addresses, maybe it's time to take a stronger stand on the practice. The facts: - a not-insignificant regional public backbone. - a private class B (172.19) on public backbone router interfaces, contrary to the guidelines in RFC-1918 (p 3). - a congested link that generates a significant number of ICMP messages. - the private source address is not being properly filtered by the ISP from reaching the public network, as required (RFC-1918 p 5). - upstream links with non-maintained (missing) in-addr entries. - traceroute downstream, after this private address, on the way to a medium-sized university, disappears into a black hole, although the university itself is certainly not in private address space. While not of earth-shaking consequence, it clearly isn't helpful for debugging the network. What kind of actions should we take? Complain to a supervisor? Construct a web page of infamy? #(name removed to protect the guilty) # I have followed and participated in several of the lively NANOG discussions. # As I recall the usual conclusion on NANOG is - let's agree to disagree. That # seems to me to leave it open to interpretation on whether this practice is # good - it saves public IP space, or bad - you can see it on a traceroute. # # I am aware of the MTU problem but how does it break ICMP? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
So you explained that his router is generating source quench messages that are treated, rightfully so, as bogus? Does he understand what source quench is for? It takes more than theory you/we all have to show that hosts such as winX PCs obey and consume such messages and modify their behavior. ----- Original Message ----- From: "William Allen Simpson" <wsimpson@greendragon.com> To: <nanog@merit.edu> Sent: Thursday, February 17, 2000 4:22 PM Subject: private RFC-1918 addresses on public routers
Usually, when a "private" address hits the bogon filters, a quiet note to the perpetrator gets the problem fixed promptly. This time, the fellow seems to want to argue. Since he's been on this list for awhile (posted here about 8 months ago), perhaps he's educable.
His characterization isn't what I remember from the previous discussion(s).
Moreover, with the recent emphasis on filtering bogus source addresses, maybe it's time to take a stronger stand on the practice.
The facts: - a not-insignificant regional public backbone. - a private class B (172.19) on public backbone router interfaces, contrary to the guidelines in RFC-1918 (p 3). - a congested link that generates a significant number of ICMP messages. - the private source address is not being properly filtered by the ISP from reaching the public network, as required (RFC-1918 p 5). - upstream links with non-maintained (missing) in-addr entries. - traceroute downstream, after this private address, on the way to a medium-sized university, disappears into a black hole, although the university itself is certainly not in private address space.
While not of earth-shaking consequence, it clearly isn't helpful for debugging the network.
What kind of actions should we take? Complain to a supervisor? Construct a web page of infamy?
#(name removed to protect the guilty) # I have followed and participated in several of the lively NANOG discussions. # As I recall the usual conclusion on NANOG is - let's agree to disagree. That # seems to me to leave it open to interpretation on whether this practice is # good - it saves public IP space, or bad - you can see it on a traceroute. # # I am aware of the MTU problem but how does it break ICMP?
WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
It used to be that "be conservative in what you send, be liberal in what you accept" was the rule. Unfortunately, that is getting less and less the case. And that is causing more and more breakage. In this case, you have two sides of the coin: 1) Those who filter ICMP's in 1918 space are being not-very-liberal in what they accept. However, given the "current" attacks which usually end up being a large portion of ICMP's from 1918 space, filtering on this space on your "net-facing" links is becoming a necessary protection on most networks. 2) Those who number internet-visible links with 1918 space are being not-very-conservative in what they send. However, given the pressure of address space conservation, this seems to be happening more and more. When a network path contains 1) and 2) in a "conservative in what you accept, liberal in what you send" configuration, breakage WILL occur. Most notably MTU path discovery will cease to function in some cases. This breakage tends to be hard to detect by the average user and/or net admin. How many people even know that MTU discovery exists or what the symptoms of breakage are? Personally, I think the most common symptom is people will call your help desk saying "This @#*$ thing doesn't work, fix it." Also, all along the path there are useful ICMP messages that get sent back. ICMP Source Quench packets for telling the sender to slow down. ICMP Unreachables to indicate the path has failed. Etc. Etc. Etc. If these ICMP packets originate from a 1918 numbered interface, breakage of that function will occur. Flows won't slow down. Traceroutes will star out on that interface, etc. (Now I've said that I'm a little worried that Traceroutes at least some of the time don't use ICMP - but regardless the symptom is the same regardless of the underlying protocol used). I think it is a given that filtering ICMP's (and everything else) from bogons is here to stay. In that context, the only way for the network to function correctly is to not send "useful" packets from 1918 space. Which includes ICMP generated by routers using 1918 space. - Forrest W. Christian (forrestc@imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------
[ On Friday, February 18, 2000 at 04:11:02 (-0700), Forrest W. Christian wrote: ]
Subject: Re: private RFC-1918 addresses on public routers
It used to be that "be conservative in what you send, be liberal in what you accept" was the rule.
That's always been an extremely wrong rule to apply to this context. That rule was supposed to have to do with protocol implementations, things like accepting SMTP commands in upper, lower, or mixed case, accepting message headers in any order, and other more interesting things in lower-level protocols. Accepting packets which claim to have come from some address that they literally could never have legally come from is negligent, if not stupid -- it is not "liberal". That's like believing that the guy who wants to come in and root around your house is from your insurance company when you can plainly see that the ID he's showing you is totally fake. In the IP world you might not call 911 right away, but you certainly don't let the packet into your network! -- 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>
When I complain, I prefer to suggest alternatives. In this case, the two that come to mind are: 1) unnumbered interfaces. I've used these with PPP for years, but as I remember, there was a problem with Ciscos. Has this been fixed? 2) host routes. Rather than creating /30 subnets for links (wasting 2 addresses for each 2 used on a link), go all the way and use /32 for each address. This make the local routing table a bit bigger, but the entries are rarely used, and aggregated at the boundaries. Thoughts? Isn't there a link around somewhere on this? What about a link for bogon filters to use at boundaries? WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
William Allen Simpson wrote:
When I complain, I prefer to suggest alternatives. In this case, the two that come to mind are:
1) unnumbered interfaces. I've used these with PPP for years, but as I remember, there was a problem with Ciscos. Has this been fixed?
I've used them in several deployments, and they work just fine. You do need at least one local interface with a real, public address to do this. When configuring the unnumbered interface, you specify which other interface (e.g. an Ethernet, or probably even a loopback) to use for IP address when needed (for ICMP messages and such).
2) host routes. Rather than creating /30 subnets for links (wasting 2 addresses for each 2 used on a link), go all the way and use /32 for each address. This make the local routing table a bit bigger, but the entries are rarely used, and aggregated at the boundaries.
Thoughts?
Isn't there a link around somewhere on this?
What about a link for bogon filters to use at boundaries?
WSimpson@UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32
-- ----------------------------------------------------------------- Daniel Senie dts@senie.com Amaranth Networks Inc. http://www.amaranthnetworks.com
participants (5)
-
Dana Hudes -
Daniel Senie -
Forrest W. Christian -
William Allen Simpson -
woods＠most.weird.com