Internet Worms and IPv6

Nice paper that dispels the myth that worms won't be able to propagate under IPv6, because the address space will be too sparse.

Posted on February 10, 2006 at 7:18 AM • 36 Comments

Comments

mpdFebruary 10, 2006 9:33 AM

I was under the impression that because of things like NAT and CIDR, IPv6 wasn't really necessary. Are there still plans to adopt it?

hkeFebruary 10, 2006 9:50 AM

There are many more advantages over IPv4 than a bigger address space, and NAT is a bad solution that barely works.

bitprophetFebruary 10, 2006 10:02 AM

hke is correct, the general concensus about NAT is that it effectively "breaks" networking. Networked applications shouldn't have to bend over backwards (like many of them do nowadays) in order to work the way they were intended to. It's a jury-rigged solution that will be fairly neatly solved with IPv6, if/when it reaches critical mass.

AnjrewFebruary 10, 2006 10:33 AM

Another source of addresses that I didn't see mentioned in the paper: The known_hosts files in the user .ssh directories, which are usually world-readable. I don't know for sure what these look like under IPv6, but I doubt if they're very different from the IPv4 version.

ruidhFebruary 10, 2006 11:02 AM

I realize people believe that NAT breaks the network (a claim I don't really understand. A remote application should not contact a port it hasn't been invited to open.), but there's no reason that has to be the case. I have a household full of desktops and I just don't want them to be addressible from the Internet at large. It's tough enough making sure they all have uptodate virus protection and are scanned for adware periodically. NAT provides me with some protection and gives me some reassurance that no one is randomly reachig into my home network.

dkFebruary 10, 2006 11:13 AM

If you think that networking is only about the desktop, http, ftp and telnet, then NAT doesn't break anything. But when you get into applications like SIP, SDP and UDP streams such as RTP, then NAT is a problem that can't be solved, and can be barely tolerated with expensive and creaky solutions such as "session border controllers" etc. The IP protocol suite was not designed for these shenanigans, and it causes a great deal of trouble trying to live with it.

Mike SherwoodFebruary 10, 2006 11:20 AM

I don't understand the claims that NAT breaks networking. I know it's a kludge, but I'd still be inclined to use it even with IPv6.

If I initiate a connection to you, that doesn't mean I want you to be able to initiate a connection to me. If it weren't for NAT taking care of this, I would set up my firewall rules to disallow it.

MikeFebruary 10, 2006 11:37 AM

"If it weren't for NAT taking care of this, I would set up my firewall rules to disallow it."

Bingo! That's the better solution.

RayFebruary 10, 2006 11:42 AM

@dk

No go learn your networking models. Anything that can't work under NAT is broken. That and I have *all* the things you talk about running in NATed environments.

IP was designed from the ground up for this to be the case. I suggest you google on "osi model".

leoFebruary 10, 2006 11:59 AM

@Ray:

Sorry pal, but you shot yourself in the foot. The fact that NAT does not adhere to the inter-layer isolation required by the OSI model that you quote (and the related ARPA protocol stack) is -precisely- why it is a pain. NAT+Port Forwarding are hacks, and ugly ones at that.

AngeloFebruary 10, 2006 12:01 PM

@Ray

"osi model" is nice, as is the TCP/IP stack - but it never got the 7 OSI layers in place...

@all (or none)
The article is nice - these guys know what they're talking about.

Grant HutchinsFebruary 10, 2006 12:03 PM

@Ray

Don't misinterpret the capability to have NATs with any sort of support for them. Vint Cerf, is one of the co-creators of TCP/IP. In his words (as early as 1999):

"Some of us feel NAT boxes are sort of an abomination because they really do mess about with the basic protocol architecture of the Internet."

from CNN (http://www.cnn.com/TECH/computing/9909/21/ip.crunch.idg/)

Grant HutchinsFebruary 10, 2006 12:05 PM

@Ray
Don't misinterpret the capability to have NATs with any sort of support for them. Vint Cerf, is one of the co-creators of TCP/IP. In his words (as early as 1999):
"Some of us feel NAT boxes are sort of an abomination because they really do mess about with the basic protocol architecture of the Internet."
from CNN (http://www.cnn.com/TECH/computing/9909/21/ip.crunch.idg/)

RayFebruary 10, 2006 12:18 PM

@leo

Yeah, I see it just the opposite of you. Yes it does take some work to make things work right with NAT and port forwarding. I disagree that they break the model, but this isn't the fourm for that convo. But I think it's a tradeoff that's well worth it.

Again this isn't the time or place so we'll just have to agree to disagree and see what happens.

As for the Vint Cerf quote. Yes, I've seen that. As brilliant as he is I think he got that one wrong. Happens to the best of us.

@angelo

That attitude is the source of many of the "problems" that various folks see and if more coders were to understand how all those pieces fit and play within the rules the world would be a better place. And that goes *far* beyond any NAT debate.

shadFebruary 10, 2006 12:29 PM

@Ray

NAT bends one of the philosophies of IP networks... keep as much intellegince at the endpoints as possible. It would be nice if you could choose NAT for its advantage of hinding network addresses, rather than arbitrary limitation of sparse addresses. In short its great for small-medium networks of client applications where a default security is valuable. It adds uneeded complexity in larger networks.

Back on topic: I agree that the more successful worms propogate by learning the network topology rather than brute force scanning. Scanning gets you notice, your more likely to hit a honeypot. But looking at addressbooks, host files, application settings, arp tables, and dns caches gives you more successful vectors to follow.

Shad

Pat CahalanFebruary 10, 2006 12:39 PM

re: NAT

NAT is broken, entirely. There are some advantages to its brokenness, but it is a violation of the network stack model.

(OSI doesn't have anything to do with the TCP/IP network stack -> OSI has 7 layers, TCP/IP only has 5 -> Application, Transport, Internet, Network Access, and Physical).

The TCP/IP stack causes a logical connection between two hosts at each layer. NAT breaks "true" networking because routers only talk Physical, Network Access, and Internet (IP), they don't talk at the TCP or App layer. So if you have a non-routable (NAT) address on one side of the router, the TCP layer is effectively broken.

This breaks the model, period.

Some protocols (TLS, for example) start a communication at one network port (25) and then negotiate an encrypted session at a higher port. TLS can break across most NAT gateways, because the NAT gateway box is assuming that the communication between host A (NAT) and host B (public) is running on port 25. If the public host (B) suddenly talks back to A on a different port, the gateway has to be able to figure out that this inbound traffic is intended for host A. This means that the gateway has to be able to keep track of all of the traffic originating from A, know what the destination hosts are, and not just translate network port numbers but also be able to dynamically "figure out" what the port number ought to be for incoming traffic.

Gateways and NAT boxes are better than they used to be, for certain, but they're a huge weak point in any network because they (by definition) have to be able to parse all of the network traffic on both sides and correctly translate the inbound traffic (all destined for some port on the public interface of the gateway) to the correct target IP on the inside. With enough hosts on an internal network and enough communications running through the gateway, you get broken connections.

AndrewFebruary 10, 2006 1:06 PM

NAT is a pain, especially if you're ever trying to do VoIP. There is no way to allow a phone behind one NAT box to connect to a phone behind another NAT box without using at least one, and usually several, server of some kind out on the "real" internet, or port-mapped there. With IPv6 and real, routable addresses, this would be easy. With NAT in the way, its a pile of kludge.

Most of the side benefits of NAT are recovered with a simple firewall. Anyone using NAT alone as a firewall "solution" should probably consult a drawing board anyway.

derfFebruary 10, 2006 1:09 PM

Regardless of whether NAT/PAT breaks anything, I'd rather have it in place to block access to misconfigured or unauthorized services than not. I prefer the model that lets only machines with which I initiated a connection gaining return access only on this same open connection.

kyleFebruary 10, 2006 1:13 PM

@ derf:
You are talking about stateful firewalling. NAT/PAT for that use case is unnecessary.

Pat CahalanFebruary 10, 2006 1:49 PM

Oh, and IPv6 has built-in IPSec. Most IPv4 installations don't use IPSec (although it is available), but it is mandatory with IPv6. This is a good thing.

NatinButNATFebruary 10, 2006 3:07 PM

I agree that IPv6 has advantages over IPv4. However, it is hard to deny that NAT adds a level of security for home Internet computer users that don't generally have a clue about complex firewall configurations, etc. The first thing I recommend to anyone setting up a home computer on a broadband Internet connection is to use a NAT box (aka cable router/firewall).

Having worked in networking since the early years of TCP/IP and OSI (yikes), I would have to say that the Internet has evolved to be different from first envisioned. When first starting in networking, the idea was that all desktop computers would talk directly to all other desktop computers (sporting both network clients and servers). In today's (and tomorrow's) Internet this is just not the case, and shouldn't be the case. The desktop computer (particularly home computers) should never be a network server to the Internet, listening on ports. There is no reason my desktop computer needs to establish a direct network connection to your desktop computer. The Internet desktop should always, and only, be a network client, initiating all network connections to the Internet, and authorizing all "in stream" port changes utilized by Internet applications.

Valdis KletnieksFebruary 10, 2006 3:07 PM

Regarding 'IPv6 has build-in IPSec':

Actually, that's a crock and a half. The IPSec (ESP and AH support) shipped with IPv6 is *the same exact thing* that is available with IPv4. The only distinction is that a networkihg stack that claims to be IPv6 must *support* ESP and AH, whereas support for them is *optional* in IPv4.

There is *NO* requirement that IPSec actually be *USED* on an IPv6 connection.
And given that the vast majority of machines that talk IPv4 already have IPSec support, there is no reason to suspect that it will actually be used under IPv6 any more than it is under IPv4.

In other words, if you're already using IPSec, you'll use it under IPv6. If you're not, you'll probably not use it under IPv6 either.

cdmillerFebruary 10, 2006 3:30 PM

@NatinButNAT

"There is no reason my desktop computer needs to establish a direct network connection to your desktop computer. "

Ever hear of P2P? How about point to point internet chat or telephony?

- cdmiller

Pat CahalanFebruary 10, 2006 3:36 PM

@ NatinButNAT

> However, it is hard to deny that NAT adds a level of security for home
> Internet computer users that don't generally have a clue about complex
> firewall configurations, etc.

It's also true that removing a car's wheels will make it less likely to be involved in an accident, since it is no longer driveable :) NAT doesn't add any security that isn't available using other methods, and it's not, in and of itself, designed as a security measure in any event. Saying it "adds security" isn't germane to a discussion over the fact that it breaks TCP/IP.

> The Internet desktop should always, and only, be a network client, initiating
> all network connections to the Internet, and authorizing all "in stream" port
> changes utilized by Internet applications.

There are a great many applications out there (desktop VoIP, for example) for which this is simply not true. You're presupposing that there is an easy distinction between a "desktop machine" and a "server machine", but this isn't necessarily the case now, and is very unlikely to be the case in the future, as more consumer-level electronics come with IP functionality.

A great many Sysadmins (myself included) would wish that this was actually the case, as it would make our lives a lot simpler.

@ Valdis

> The IPSec shipped with IPv6 is *the same exact thing* that is available with IPv4.

I never said it wasn't (although, in fact, it isn't the *same exact thing*, at least according to Cisco: "IPSec functionality is similar in both IPv6 and IPv4; however, site-to-site tunnel mode only is supported in IPv6." - I didn't fact-check this, fwiw.)

My point is that currently you can buy a product that "works over IP" that won't support IPSec, because it is IPv4. If you buy a product that is IPv6, on the other hand, you *know* it can do IPSec. Machines with an IP address aren't always a computer terminal with an OS.

> And given that the vast majority of machines that talk IPv4 already
> have IPSec support

Er, this isn't precisely true. Windows98 didn't ship with IPSec capability, you have to add it (although it is available), and there are a great many installations out there that still have Windows98 clients.

> If you're already using IPSec, you'll use it under IPv6. If you're not, you'll
> probably not use it under IPv6 either

There is a barrier to entry to convert an existing IPv4 enterprise to IPSec capability. Anyone that's gone through a VPN rollout that still has Windows 98 clients can attest to this. Removing some of those barriers can make the adoption easier, no?

BjornFebruary 10, 2006 4:17 PM

Increased security from larger address space is just security-by-obscurity once again. A good thing to have, but no substitute for the real thing.

The good thing about the small address space of Ipv4 is that it gave us NAT. NAT will not go away with IPv6 - it is too useful for that.

LongwalkerFebruary 10, 2006 5:48 PM

IPv6 isn't going to make NAT disappear from the SOHO market anytime soon. Going to fully routable addresses will be too expensive and too much of a pain to manage.

ISPs charge extortionist rates for additional IP addresses per account. No matter how much IPv6 lowers the cost of IP addresses, broadband ISPs aren't going to pass the reductions on to end users. Being both inherently greedy and essentially protected monopolies, broadband ISPs are going to continue charging 5$/month+ for each additional IP address, if they make additional IPs available to residential customers at all. NAT boxes have a much lower TCO in this environment.

The other issue is maintainability. It's much easier to create and manage a firewall rule that restricts private traffic to 192.168.x.x rather than a rule that needs to work with a bunch of dynamic address that could be allocated anywhere in your provider's netbloc There's also the issue of NetBIOS name lookup. Give every computer on a SOHO LAN a dynamic routable IP--likely with some of them on a different subnet--and suddenly every LAN needs a WINS or DDNS arrangement just so the machines can see each other.

NAT has its drawbacks but it certainly does make things easier down at the SOHO end of the scale.

Pat CahalanFebruary 10, 2006 6:18 PM

> ISPs charge extortionist rates for additional IP addresses per account.

That's true to some extent, currently, for small concerns.

On the other hand, when I worked for a dot com with two different ISPs and several dedicated lines, netblocks were easy to arrage with a phone call.

> It's much easier to create and manage a firewall rule that restricts private
> traffic to 192.168.x.x rather than a rule that needs to work with a bunch of
> dynamic address that could be allocated anywhere in your provider's
> netbloc

IPv6 is still a ways off from being the commodity structure of the Internet. Saying that current business practices by ISPs that manage IPv4 networks are going to carry over to IPv6 networks doesn't take into account that the market *will* change significantly when IPv6 devices are common.

I suspect that you'll see more large-scale IPv6 deployments when cell carriers get into the act, and MAN/WAN wireless protocols become mainstream (802.16e, 802.20, whichever comes out on top).

Portable devices are going to drive this changeover, I would imagine. We're still several years out...

gregFebruary 10, 2006 7:52 PM


>ISPs charge extortionist rates for additional IP addresses per account. No matter how much IPv6 lowers the cost of IP addresses, broadband ISPs aren't going to pass the reductions on to end users.

Why not? I can get a static IP number for my home PC for the price of a burger right now. IP6 will make them cheaper by nature of the huge space avalible. Competion will mean it will get passed on.

I'm at uni right now and all the machines have static IP numbers. Its awsome. I can connect with the protocol I choose. Not just the NAT compatable stuff.

Roll on IP6

Davi OttenheimerFebruary 10, 2006 8:03 PM

Didn't Marley say something about "beware the dready NAT"?

I'm still looking for who said worms will not be able to propogate in IPv6. The paper starts out by saying this has been asserted, but by whom/where? Myth or strawman?

It seems somewhat self-evident to me that as long as you have residual IPv4, you would still have issues with propagation. And then there's the simple trade-off of convenience/security that is likely to lead people to derive their IPv6 setup from extant IPv4 (easier transition, yet reduction of real address space). So if the new system were setup without any connection or relevance whatsoever to the old, then it might be more resiliant. But the old legacy/compatibility and continuity thing kind of gets in the way of a secure break, yet again...

riproarFebruary 12, 2006 7:08 PM

@ kyle:
"You are talking about stateful firewalling. NAT/PAT for that use case is unnecessary."

Unnecessary, true. But it keeps a lot of inexperienced users safe. If you are using NAT, you are almost definitely protected, unless you start changing options. With a firewall, how does the average Joe know whether or not it is doing anything? If it is on or off? Default deny or default allow?

I like the "default deny" and "no doubt it's working" and "plug and play" protection NAT provides for the masses. For security, NAT just works. Wouldn't you say the millions of NAT routers out there are one of the best things to happen to slow down worms among home users?

(For P2P and IP telephony, NAT is indeed a kludge.)

Ari HeikkinenFebruary 12, 2006 9:09 PM

In my experience, NAT only works for pure clients and is problematic even for them (I never use NAT for any of my own boxes if I have a choice). Anything server and I'd stay as far as possible from it.

LMAObehindNatFebruary 13, 2006 10:10 AM

"millions of NAT routers out there are one of the best things to happen to slow down worms "

Which is easier to drown in, an ocean or a river? I don't think any slow-down which may have occurred because of NAT is significant enough to crow about. Once behind the NAT router, no matter how it got there, a significant number of NAT routers will gladly open a port requested by any worm.

Also, there are as many broken NAT boxes as there are firewalls with crappy interfaces. Both are huge problems.

As long as the NAT crutch is in place, why should anyone write a newbie-interface to a firewall? That's the only reason the home-user-wretches think "firewalls are hard" - they need better, easier to understand interfaces.

LarryGJuly 17, 2007 2:17 PM

So with NAT entrenched in our networks, is it likely that entities like companies will just buy IPV6 gateways into the enterprise and won't care if equipment inside is IPv6?

Leave a comment

Allowed HTML: <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre>

Photo of Bruce Schneier by Per Ervland.

Schneier on Security is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc..