Using RFC 1918 IP Addresses on Internal Routers?

braek asks: "Our network has expanded to the point that I have about 6 separate network links to remote networks. I would like to avoid using public IP addresses for the routers to conserve my limited global IP addresses, and I don't expect any additional IP's for a while. :( What do you guys think about assigning internal routers a private, RFC 1918 IP address, like 10.0.0.1 or something? (For security, RFC 1918 addressess would be filtered at the border routers.)"

"I am testing this right now, and routing seems to work fine, the only problem I can think of, is when someone does a traceroute, it will show up like:

10   120 ms   131 ms   120 ms  152.63.67.97
11   130 ms   130 ms   131 ms  66.141.21.1
12     *        *        *     Request timed out.
13   130 ms   130 ms   140 ms  66.141.21.185

Hop 12 is the router with the private RFC 1918 address, and I am assuming it is not responding to a traceroute because the IP is not globally routable. However, all the clients behind the router have complete, unabashed network access. What problems may one encounter if implementing this kind of addressing scheme?"

Comments

Only one issue

[Xenophon Fenderson,]

When I traceroute from my Road Runner Pro connection (which uses statically-assigned routable IP addresses), I see at least one 10/8 network:

eco-fs1:~>traceroute -n slashdot.org
traceroute to slashdot.org (64.28.67.150), 30 hops max, 38 byte packets
165.29.199.11.986 ms1.920 ms1.915 ms
210.55.160.111.023 ms11.421 ms10.648 ms
324.29.1.778.931 ms9.818 ms9.734 ms
424.29.1.12910.547 ms10.612 ms9.011 ms
524.29.1.17710.051 ms9.535 ms18.987 ms
...and so forth.

Technically, this is the Wrong Thing. Likewise, your routers should never respond to or generate traffic using RFC 1918 addresses.

Re:Only one issue

[Splork]

My cheapo DSL ISP (telocity, now DirecTVDSL) does this as well.

It's not the wrong thing to do provided, as is the case, my computers never have a need to talk directly to my ISPs intermediate routers and their intermediate routers never have a need to talk directly to my DSL hosts. So it shows up as an actual hop in the traceroute, big deal; you might as well think of it as your packet being tunneled through a cloud of routers running another protocol.

I am still free to use those addresses on my internal network all I want without any problems.

(well sort of, they make http://10.5.1.2/ hit the web interface on their proprietary dsl modem to check status, gather line speed and traffic statistics, etc. but so what; there's 24 million 10/8 addresses)

Re:Only one issue

[anticypher]

I see at least one 10/8 network:
2 10.55.160.1 11.023 ms

Nope. It looks like a 10.55.160.1/30 point to point link between the uBR headend router for your neighborhood and the core routers in Cincinnati. Since the uBR is only collecting traffic and passing it on to the core, it never needs a routable interface, hence RR is doing a technically valid thing.

There is nothing wrong with using an RFC 1918 address for internal links. Many ISPs use them for point to point links to conserve IP use. So what if RR is using a 10 address on one of their internal links? Your packets are still being routed, your traceroute got to /., and you were able to post wrong information :-)

Its not the wrong thing to conserve IPv4 address. Its good practice, every one should be doing it.

Routers should respond to all valid IP addresses, even RFC1918 addresses. What shouldn't be done is to route those packets to the internet. If your border routers are participating in BGP4, then they should be dropping any packets with source or destination matching RFC1918, and should ignore (filter) any route to an RFC1918 net. There are lots of badly configured border routers out there spewing route advertisements for private network ranges, just learn to filter them out, and make sure you filter your own out.

the AC

We do this...

[john@iastate.edu]

One thing to note is if you are using DHCP the forwarded packets will have the 10.x.x.x address (assuming that is the primary address of the router interface).

You'll just need to use the 'shared network' statement (or equivalent if you are not using ISC's dhcpd) to take care of this.

Can and Must

[fm6]

It's a mystery to me why this isn't considered mandatory. People sweat blood building firewalls and packet filters and block off port numbers that people need -- and the kiddies still find a way through. Using a private network space is the ultimate access control -- for anyone outside your network, internal machines simply don't exist.

Re:Can and Must

[dragonfly_blue]

Uh... until they compromise an internal host, or internal router, that is. If you think that you can lock down a network simply by using private IP's, think again.

Here is one scenario; compromise a Windows machine on 10.0.0.0/8 by sending it an email with an auto-executing file type. Have that executable run a trojan with an IRC daemon. Have that IRC daemon connect back to a channel where you have channelops.

Once you can issue commands to the shell running on that Windows box inside that network, use the compromised machine to scan every other host on the internal network for vulnerabilities. You can even use port forwarding on the compromised machine to directly attack other hosts, in a fashion similar to having a VPN. Or, you can bootstrap Gnu-style utilities such as CygWin or NT rootkits to turn that Windows machine into a fairly powerful Unix emulator. Take your pick.

The attack vectors available for compromising a host on a private subnet are many; once a host is compromised, the attacker can do whatever they'd like inside your network, "private", or not.

Re:Can and Must

[ryanmoffett]

Not quite. Let's say you compromise a host on the 10/8 network. If it attempts to make an outbound TCP connection to an IRC server, the IRC server will not be able to respond back to the 10/8 host because RFC1918 routes are going to be filtered at some point back to the client and the TCP 3-way handshake won't even complete. UDP attacks in one direction from the client to the public would be possible, but the RFC1918 source address would most likely be caught by an ingress filter at the remote end.

Now, most likely, that 10/8 host gets NAT'd to a public address through a firewall. In this case, the IRC scenario is not only possible, but a real tactic used to get past firewalls. Some, firewalls such as the Cisco PIX make it easy to not care about your outbound traffic, so a client making outbound connections to IRC servers isn't necessary going to even be noticed. This is why you have to implement egress filtering on your firewalls and/or routers to block what your users have access to should they ever get trojaned.

Re:Can and Must

[Bryan Andersen]

Uh... until they compromise an internal host, or internal router, that is. If you think that you can lock down a network simply by using private IP's, think again.

This is why smart admins only use them as yet another layer in their defense perimiter.

Unnumbered IP?

[ajvtoo]

If your six separate network links are simple point-to-point links, have you considered using unnumbered IP on these links to free up some IP space?

See http://www.cisco.com/warp/public/701/20.html for some more information.

In and out

[fm6]

Hey, not system is beyond comprimise. Admins who life with that fantasy surely have the least secure systems of all!

But I was comparing the private network approach with the firewall approach. Neither would hold up with an internal system comprimised. Indeed, it's hard imagine a security that would.

Hmm..

[_ganja_]

There isn't really a problem with what you are doing, the only thing I don't really like about doing this is the management aspects when the implimentation gets a little large. More on that in a bit but first, technically, the golden rule here is as long as these addresses are of course unique and stay in your own AS you'd be fine, I'd personally go one further and would keep them only in your IGP just to be safe in case someone screws your bgp filters etc.

I'm a CCIE and been networking 11 years now, 6 with Cisco and I'd only do this is if I really had too and here's why: management of address space. I'm sure (hope) your management of all your public address space is organised and clear. Furthermore nobody would dream of adding a box to the network with a public address without asking you or another admin who would assign one, which case you would go to your speadsheet (or QIP / another tool), allocate one and record the details. With private address space people tend to just add boxes and subnets and pick an address from random out of the air. This is where time consuming issues come about with overlapping address space. If your network is going to stay small and you have full control over all the addresses then you shouldn't have much of a problem but if the network is going to grow a larger, think about the extra admin you might have to do and also if you were to be hit by a bus would the next guy understand it.

You have some cisco semi-hacks to help you out also such as unnumbered links and also note /31 subnets are available in newer IOS revisions. At the end of the day I don't know how large you're network and it's exact design, its your choice at the end of the day, just make sure it won't bite you in the ass in the future.

RFC1918 has almost universal effective use.

[Bob_Robertson]

I've been doing this WAN/LAN thing since 1982. Ever IP shop save one that I have worked in has used RFP1918 addresses.

I cannot think of a situation, even a single end-point PC, that would not benefit from intellegent and thoughtful use of RFC1918, and even that single PC, if it offers no externally accesses services, has no need for a globally routed IP address of its own.

For all its faults, AOLs use of externally invisible addresses has meant 33 million surfing consumers without wasting routable IP addresses. The masses are (comparitively) secure from DOS and crack attacks, and the technically astute ones can still get little patches that let IP native software on their AOL attached machine work fine.

Even the Mom&Pop dial-up ISP customer, or DSL or Cable subscribers can benefit by only paying for globally routable addresses if/when they want to offer services, or the service provider can simply not offer such routable addresses. The vast majority of home users won't notice the difference.

And anyone with an internal point to point circuit can use RFC1918, anyone who uses a "real" router to link to their ISP (that includes *nix running IPMasquerade) benefits by putting their internal office on RFC1918 address except those few machines that are offering services to the outside world. And if their business depends on it, why are they putting the server in their office anyway? That's what professional datacenters are for.

Of course it can cause problems if done randomly or without consideration that yes indeed this same "10.0.0.1" is used by thousands if not hundreds of thousands of other 'Nets around the world.

However, the benefits of implementing RFC1918 far outweigh the potential problems. At the absolute worst, two sites might have to use masquerade between them to hide the fact that years before they knew they would be working together, they both used 10.0.0.1. That's it, that is the one "danger", and it's little more than another option on the (hopefully used, like a condom) firewall that is also installed between the two offices.

Re-reading, this is in fact a "big picture" spewing on my part. I really wish the "doom and gloom" nay-sayers on both sides, the "We're Running Out Of Addresses" and "RFC1918 Use Is Dangerous" would take cold showers and relax.

Extensive use of RFC1918 is saving lots of money in those places like Asia where routable addresses cost a bundle, and putting off IPv6. Renumbering at some point is the greatest "danger" that any use of RFC1918 can cause, and not using it will require renumbering any time someone changes ISP's anyway. Such is not the case if you're already using unrouted addresses. Something to think about, with the merger/failure cycle in ISP's, ne?

So my advice, do RFC1918 where ever you can!

And for the "I'm Sid, so there" urge, the CCIE "certification" didn't exist yet at the time when I took all the Cisco classes. So There!

Bob-

Trace will show RFC1918 if YOUR ISP uses it...

[Bob_Robertson]

RFC1918 addresses will show up any time your ISP uses it.

RFC1918 source/destination packets are dropped at the *edge* routers, not "every" router. By edge I mean AS-Number borders, my experience is that anyone with the technical know-how and need for their own AS-number also usually knows to filter those packets to and from their BGP peers and default providers.

Yes, to and from. For laughs I used to put logging on the border routers, to catch packets to/from RFC1918 addresses, as well as BGP advertizements of RFC1918 address blocks. It was amazing the otherwise reputable ISP's and major companies who forgot to filter those things out! Lets just say that it was one reason for my buying my first AMD chip!

Bob-

NANOG

[The Madpostal Worker]

This is a topic that has been flamed^H^H^H^H^H debated to death on the North American Network Operators Group(NANOG) Mailing List

Its a great list, and has a lot of very knowledgable people on it.