Alex Bligh wrote:

Possibly users behind your filters are tracerouting through somewhere which has PtP links configured in RFC1918 space, and you are seeing ICMP TTL exceeded back from these addresses. Some people allege configuring publicly visible PtPs to RFC1918 addresses is not bad practice. YMMV.

And other people allege that it is easier to use RFC1918 space for /30's than having to deal with ARIN to get more space. More than just using up allocated space (I only have a dozen or so such links) is the issue of fragmenting the space. I put all my /30's that don't have a specific need for public addresses in 172.30.0.0/16 (I call it "30 space"). One advantage that RFC1918 doesn't mention is that having this space available helps keep down the amount of address space fragmentation so I don't have to do so much renumbering to keep large enough free space for big customers. My outbound access lists block it, so you should never see 1918 sources coming from me. You should see "* * *" instead, even if you don't block them coming in to your net. I also run some 1918 traffic inside. For example, I have DNS running on 172.16.4.4, 172.16.5.5, 172.16.6.6, and 172.16.7.7. There's no actual subnet for them. They are just IP aliased and statically routed to the correct box. The next time we renumber, we won't have to change DNS numbers for a large chunk of our customers. Again, none of this should be leaking because the servers have public addresses as the real address for their interfaces, and the access lists take care of any other strays. -- Phil Howard KA9WGN phil@intur.net phil@ipal.net

...

My outbound access lists block it, so you should never see 1918 sources coming from me. You should see "* * *" instead, even if you don't block them coming in to your net.

I think this sucks big-time. It wouldn't be quite so bad if traceroute were the only thing that were broken by it (though I do like my traceroutes to work properly too), but when all ICMP traffic from such a router is hosed, and one of the links my packets are trying to hop onto through such a router is down, then I'm a particularly unhappy camper (if I could see the !H or !N I'd still be unhappy of course, but not

...and I'd certainly like to see my ICMP unreachables which are vital to path MTU discovery not blocked. -Phil

Phillip Vandry wrote:

...

...

My outbound access lists block it, so you should never see 1918 sources coming from me. You should see "* * *" instead, even if you don't block them coming in to your net.

I think this sucks big-time. It wouldn't be quite so bad if traceroute were the only thing that were broken by it (though I do like my traceroutes to work properly too), but when all ICMP traffic from such a router is hosed, and one of the links my packets are trying to hop onto through such a router is down, then I'm a particularly unhappy camper (if I could see the !H or !N I'd still be unhappy of course, but not

...and I'd certainly like to see my ICMP unreachables which are vital to path MTU discovery not blocked.

Since the road doesn't narrow, this won't be a problem on these links. This is taken into consideration when the addresses are assigned. There might be others doing this improperly. -- Phil Howard KA9WGN phil@intur.net phil@ipal.net

Greg A. Woods wrote:

[ On Friday, April 23, 1999 at 00:59:06 (-0500), Phil Howard wrote: ]

...

Subject: Re: address spoofing

My outbound access lists block it, so you should never see 1918 sources coming from me. You should see "* * *" instead, even if you don't block them coming in to your net.

I think this sucks big-time. It wouldn't be quite so bad if traceroute were the only thing that were broken by it (though I do like my traceroutes to work properly too), but when all ICMP traffic from such a router is hosed, and one of the links my packets are trying to hop onto through such a router is down, then I'm a particularly unhappy camper (if I could see the !H or !N I'd still be unhappy of course, but not throwing my arms up in disgust at the guy generating the * * *). Of course even an upstream provider from my own home network does this, depsite the fact I've chided and cajoled and otherwise bugged them to change it.

So are you making a case to allow RFC1918 source addresses out into the network?

Now in Phil's networks perhaps it is normally impossible for illegally formed host-unreachables to be generated even in the face of outages because hopefully he's got everything running fully redundant, but *I* see this kind of breakage from all kinds of places many times a day in the filter logs on my networks and those of my clients.

There's also not really any difference between you blocking those packets on the way out, and me blocking them on the way in -- the end result is that all ICMP and whatever else from those routers is busted.

Perhaps router vendors can figure out some way to ensure that all packets generated by a router get a unique, valid, non-RFC1918 number when they would otherwise have used an RFC1918 number. Maybe people who think they need to use RFC1918 should instead just hide all their internal crap in a big ATM or FR cloud.

How do you hide an IP network? If you're proposing another set of addresses be reserved for uses like this, then I'd be in favor of it with you. Using RFC1918 is certainly not the best way to do this, but using allocated space is no better as long as allocations are tight.

Then there's the crap I see in the filter logs on my HTTP transparent cache and proxy machines that seems to indicate people have publicly published URLs (perhaps with publicly visible DNS) that point at RFC1918 space..... Grrrrr.

People don't know how to separate their internet DNS from intranet DNS. Or maybe they don't want to put the money into that kind of structure. If BIND could be modified to deliver different results depending on the source of the request, or it's interface, then it might become easy for people to setup DNS to avoid this. -- Phil Howard KA9WGN phil@intur.net phil@ipal.net

Andrew Brown wrote:

...

If BIND could be modified to deliver different results depending on the source of the request, or it's interface, then it might become easy for people to setup DNS to avoid this.

not running a current bind, eh? :P

the 8.x.x series bind dynamically picks up and drops interfaces as they appear and disappear, and can be told on which interfaces to listen. so...you can actually have a publicly available, non-recursive name server to answer the queries for the zones for which you need to be authoritative on the interface(s) to which those zones are delegated.

then, you can have (if you want) another bind listening on other interfaces for other stuff. like the "internal dns" server that you mentioned. or maybe a recursive, caching-only server that listens only on 127.0.0.1. of course...they can speak to each other if need be. :)

I tried 2 instances of BIND and they didn't work right. One functioned and the other played dead (very dead ... as in the process blocked and would not wake up). One needs 2 separate machines to get it to actually work right (times the amount of redundancy desired). If you know the magic to make it work right, I'd sure like to know. Maybe some kind of lock somewhere? -- Phil Howard KA9WGN phil@intur.net phil@ipal.net

The third edition "DNS and BIND" books, from O'Reilly <http://www.ora.com> also goes into detail on how to do it. ----------------------------- Roeland M.J. Meyer Morgan Hill Software Company, Inc. http://staff.mhsc.com/~rmeyer mailto://rmeyer@mhsc.com ----------------------------- You can always tell the people that are forging the new frontier. They're the ones with flaming arrows sticking out of their backs and looking a little charred around the edges.  

-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Andrew Brown Sent: Sunday, April 25, 1999 8:10 AM To: Phil Howard Cc: nanog@merit.edu Subject: Re: address spoofing

...

...

then, you can have (if you want) another bind listening on other interfaces for other stuff. like the "internal dns" server that you mentioned. or maybe a recursive, caching-only server that listens only on 127.0.0.1. of course...they can speak to each other if need be. :)

I tried 2 instances of BIND and they didn't work right. One functioned and the other played dead (very dead ... as in the process blocked and would not wake up). One needs 2 separate machines to get it to actually work right (times the amount of redundancy desired). If you know the magic to make it work right, I'd sure like to know. Maybe some kind of lock somewhere?

the trick is to tell them specifically to listen on different interfaces. if you don't do that, then they will collide. other things (such as a different query or forwarding port, a separate pid file, etc.) are also rather necessary.

i will attach a small shar file that paul vixie posted to the bind-workers mailing list a little over a year and a half ago that demonstrates exactly this.

-- |-----< "CODE WARRIOR" >-----| codewarrior@daemon.org * "ah! i see you have the internet twofsonet@graffiti.com (Andrew Brown) that goes *ping*!" andrew@crossbar.com * "information is power -- share the wealth."

Greg A. Woods wrote:

...

So are you making a case to allow RFC1918 source addresses out into the network?

Huh? No, I thought I was saying very much the opposite! I don't want my upstream provider to use RFC1918 on inter-router links, but they do anyway. I'd like them to filter those addresses too, but they won't.

I do agree they should be filtered out. At what point should we draw the line and say who can, and who cannot, use RFC1918 addresses on links? My first thought would be any link over which traffic from more than one AS transits, or between AS's, should always be fully routable. Any better ideas?

If you do all your internal routing over ATM or FR virtual circuits then you won't need to (and in fact cannot) use IP numbers for those circuits -- it all looks like the physical layer from IP's perspective (the theory being that if you don't need IPs for inter-router links then you won't be using precious unique IPs and feel the pressure to use RFC1918 numbers instead). I'm certainly no expert at this, but from the outside I've seen it done quite successfully. It sure cuts down on the hop count visible from traceroute too!

The FR cloud will look like one hop as far as I can see. But none of my RFC1918 links are FR or ATM. They are plain DS1/24*N (aside from the internal aliases, but those aren't even links).

It's damn near impossible to debug from the outside, of course, but sometimes that's desirable! ;-)

I remember the first place I put up a firewall, I blocked pretty much everything, include ping (from outside) and traceroute (from outside). The reason was to conform to corporate policy regarding confidentiality of facilities and resources to guard against competitors snooping around. Even so much as seeing how many IPs would answer ping was considered to be proprietary company information. It was my goal to limit access to just those resources required for the company's business. I think I did it pretty well. I only got one complaint about it and that was from Randy Bush.

...

If you're proposing another set of addresses be reserved for uses like this, then I'd be in favor of it with you. Using RFC1918 is certainly not the best way to do this, but using allocated space is no better as long as allocations are tight.

Using any other set of reserved addresses would have exactly the same problem as using RFC1918 addresses has. The only two viable options are to either use globally unique addresses, or not to use any IP routing internally at all.

I do see another possibility. I would call these "public overload" addresses. By public, they would be allowed to transit as sources. By overload, more than one use at a time could be made, although they should be unique within an administrative scope much as RFC1918 is. As to the impact that may cause on the net, I cannot say. There could very well be more impact than RFC1918 has, so it's probably it a good idea. I just see it as a possibility.

...

People don't know how to separate their internet DNS from intranet DNS. Or maybe they don't want to put the money into that kind of structure. If BIND could be modified to deliver different results depending on the source of the request, or it's interface, then it might become easy for people to setup DNS to avoid this.

Yes, it can be done, but even I am not yet using the latest software, which makes this much easier, on all the machines I manage.

I haven't seen how to do it in the newest BIND. I tried some tricks but haven't managed to accomplish it. -- Phil Howard KA9WGN phil@intur.net phil@ipal.net

...

Greg A. Woods wrote:

...

my upstream provider to use RFC1918 on inter-router links, but they do anyway. I'd like them to filter those addresses too, but they won't.

I do agree they should be filtered out.

At what point should we draw the line and say who can, and who cannot, use RFC1918 addresses on links? My first thought would be any link over which traffic from more than one AS transits, or between AS's, should always be fully routable. Any better ideas?

Somewhere along the lines of this thread, the point has been lost (IMHO).

Perhaps the original point was lost, or has been obscured. There are other points that have been brought up that impact the original. That's why they always get brought up.

If a provider uses 1918 addresses on internal links, who cares? And when you say 'filter' them, do you mean filter them in routing announcements, or filter any traffic to/from that ips?

Filter them totally as needed.

If the former, than thats good, you should do that; it should be part of your martian filters. If the latter, thats fine too, but traceroutes will '*' on those hops.

But, once again, who cares? Conservation of IP space is good at worst.

I'd agree.

...

...

won't be using precious unique IPs and feel the pressure to use RFC1918 numbers instead). I'm certainly no expert at this, but from the outside I've seen it done quite successfully. It sure cuts down on the hop count visible from traceroute too!

Using 1918 space will have no bearing on hop count or visibility of the hop. Thats rediculous.

The context was missed. I was referring to the FR cloud. -- Phil Howard KA9WGN phil@intur.net phil@ipal.net

Daniel Senie wrote:

My take on this is the line is at the edge of a single, end customer. In other words, a company which buys IP service from an ISP may use RFC 1918 addresses internally. An ISP should NOT use private address space in their own network for any equipment, with the exception of their administrative or management functions, provided those functions are restricted in scope to their own use. There should be no gear in the path from an end customer to peering points which use private address space.

The reason I arrive at this conclusion is for the sake of the end user. The purpose, in my opinion, of the private address space described in RFC 1918 is to allow users to build large networks without consuming public address space. The goal was to provide someplace for private networks to go that'd be unique to themselves, provided they didn't talk to another private end user. Now what happens when a company has already used 10.x.x.x and built a large network, and uses NAT or proxies at their border, but their upstream ISP decides to also use 10.x.x.x for everything? There is real potential for conflict.

What I find most annoying about my upstream using private address space for their own use is it takes away my ability to use that address space as an end customer, and could have required me to renumber to ensure there were no conflicts.

The conflict potential is real, but it is also discussed with customers. We'll deal with those conflicts. It's not an Internet issue, but rather, and issue between a provider and customer. If a customer asks for a non-RFC1918 link, we'll give them one. I'd like to see someone do something about the problems that happen, or happen to a greater extent, when /30 links are allocated out of routable space. Large ISPs have enough address space to dedicate a whole netblock to their links in one place. Small ISPs won't have that much. Yet with turnover, fragmentation still happens, and ARIN doesn't take SWIPs for /30. Thus we end up with holes that look like they are big enough to assign and use, but they aren't. Then we have to renumber to aggregate the holes. Since they are links, that means coordinating with customers to renumber their routers. Then there's the use of RFC1918 for DNS. It's entirely optional for our customers, as they can use the real address instead. We do this just to minimize the number of changes needed when we do need to renumber (which will happen again soon, and probably again in 2000 or 2001 as we grow). You have a bigger network w/o these problems, right? -- Phil Howard KA9WGN phil@intur.net phil@ipal.net

everybody seems to be focussed on the 1918 space packets and the explanations seem half reasonable. as Daniel Senie <dts@senie.com> said, the rules of the road say i should not be seeing packets from 1918 space. i.e. at best these come from broken places. but the uglier symptoms are packets from my own address space deny ip 147.28.0.0 0.0.255.255 any (6 matches) the loopback network deny ip 127.0.0.0 0.255.255.255 any (375 matches) and attempts on 111 and 2049 deny udp any any eq sunrpc (9 matches) deny tcp any any eq 2049 (494 matches) randy

In message <m10aUqK-0008G4C@rip.psg.com>, Randy Bush writes:

everybody seems to be focussed on the 1918 space packets and the explanations seem half reasonable. as Daniel Senie <dts@senie.com> said, the rules of the road say i should not be seeing packets from 1918 space. i.e. at best these come from broken places.

Perhaps because no one really wants to consider the implications of the second set.

but the uglier symptoms are packets from my own address space

deny ip 147.28.0.0 0.0.255.255 any (6 matches)

the loopback network

deny ip 127.0.0.0 0.255.255.255 any (375 matches)

While it is possible to come up with examples such as end sites randomly picking IP addresses and using those, and originating those packets onto the Internet, most of these packets I've ever seen have been scanning or probing or active attacks. Sadly these attacks would be impossible to trace as there exists no real time communication system between Nocs where "security" issues are addressed. I can understand some of the political reasons why companies would prefer there NOCs not be able to address "security" issues. And I can understand why an end user reporting the problem has difficulty in reporting problems to networks that they aren't a customer of. I can't for the life of me understand why companies with clue and companies with tons of money, and companies without either, typical only have one "security" person who happens to be out, and even if paged won't get back before the attack goes away, then gives you the lame answer "I don't see anything now", as if you made it up. The only possible conclusion I feel comfortable with, aside from none, is that these issues are not significant from an operational perspective and security must be handled at the end sites. My gut feeling is that we don't see nearlly as many amplifier attacks in the last six months as we did in the six previous. (Thank CAR?) Primarily because these were severe enough to cause operational issues. The same could perhaps be said of mail relaying, which I don't see nearly as many operational issues from now as I did a year ago. (Hasn't much affected levels of junk email I receive tho.) If there is a real impact of random bogon packets, I don't see much solution other than real time tracing, as source ingress filtering is only marginally effective in preventing them (or URFP verfication).

and attempts on 111 and 2049

deny udp any any eq sunrpc (9 matches) deny tcp any any eq 2049 (494 matches)

randy

I've got customers that actually use these, so I couldn't filter those without problems, although probably the customer could work around those peices of software... --- jerry@fc.net Insync Internet, Inc. | Freeside Communications, Inc. 5555 San Felipe, Suite 700 | PO BOX 80315 Austin, Tx 78708 713-407-7000 | 512-458-9810 http://www.insync.net | http://www.fc.net

...

but the uglier symptoms are packets from my own address space

deny ip 147.28.0.0 0.0.255.255 any (6 matches)

I have vague memory of an old attack using ping with source address equal to broadcast address of the target net.

That is over and above TCP connection hijacking, server attacks with half openned TCP connections and such fumy things. On the other hand, given you seem to have only 6 incidences, looks more like screw up than real attack. Regards, John Leong -- --------------------------------------------------------- Bell Labs Research johnleong@research.bell-labs.com 4995 Patrick Henry Dr. Tel: 408-567-4459 Santa Clara, CA 95054 Fax: 408-567-4448

There have been a couple of things brought up here which bother me. First of all, everyone seems to think that this paragraph:

"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. If such a router receives such Information the rejection shall not be treated as a routing protocol error."

means that packets with source addresses from RFC 1918 space should not be permitted on the global internet. While I agree that RFC 1918 addresses should not be used on internet visible interfaces, I'm unaware of anywhere in the RFC's where it says that "routers should be configured to reject packets coming from RFC 1918 space." In fact, I can think of several things which this will likely break, such as MTU path discovery. Note that "routing information" is NOT the same as "packets from RFC1918 space". Also, I've seen several people filtering stuff on borders such as: deny tcp any any eq 2049 (and several other >1024 port numbers) Remember, on machines where nothing is bound to 2049, 2049 is a perfectly acceptable port to use for ANY type of TCP connection. Only ports below 1024 are reserved. If you happen to have a filter on say port 2049 between you and the destination and your TCP implementation gives you 2049 for a given TCP connection, the connection will fail. - Forrest W. Christian (forrestc@imach.com) ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------

On Fri, 23 Apr 1999, Andrew Brown wrote:

well...there is that part about

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

that sort of clears it up for me.

Hmmm.. I wonder how I missed that. Thanks for straigtening me out :) - Forrest W. Christian (forrestc@imach.com) ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------

...

anyone have clues other than net slime and misconfigured nats?

I actually have never seen a NAT box do this (but would like to hear about such cases). The NAT implementations I've worked with have been extremely good about avoiding leaks.

On a related issue, yesterday I discovered a number of sites that claimed to have a firewall in place with RFC 1918 space on one side and Internet space on the other. on investigation, it turned out that the firwall was a router, routing the RFC 1918 space and consisted of specific ACLs for services. I came away impressed. --bill