Obsession With Firewalls Could Hinder IPv6

DosIgriegas writes "The obsession with firewalls in IPv6 may result in some of the quirks of IPv4 reappearing. Ars Technica has an article looking at the topic in depth, exploring the technical challenges of securing the new protocol, and looking a the re-emergence of old problems in new guises. 'Ironically, what's required to make IPv6 work through a stateful firewall is almost identical to what's required to make IPv4 work though NAT. This means the IETF's efforts to keep IPv6 NAT-free in order to make protocols do their job without messy workarounds are defeated by the notion that everything should be firewalled.' If we decide to stick with firewalls in IPv6, we'll see many of the same hard-to-diagnose network problems that we have with IPv4."

Comments

NAT needed?

[jshriverWVU]

I thought one of the reasons to migrate to IPv6 was to pump up the number of IP's available. If tis is true, we may not need NAT each device be it a computer, Wii, or Tivo could have it's own dedicated IP.

Re:NAT needed?

[drinkypoo]

The issue isn't NAT. We're not talking about using NAT. You're so far behind the curve that you aren't even visible over the horizon any more. The issue is that many protocols today are based on more than just opening a single outgoing TCP connection, or just spraying some UDP. They require connections on multiple ports and often to a variety of hosts. If there is a single firewall it must dynamically configure firewall rules for these applications or they don't work properly. You have to have a single firewall for security; you can't just have incoming traffic on your corporate net without a firewall. For people with a small home network and just a couple of machines you could use just the firewalling on your system (especially if your system is *BSD or Linux.)

Re:NAT needed?

[geminidomino]

"Putting a firewall on the system it is meant to protect is like wearing a bulletproof vest on the inside." -- I can't remember.

Re:NAT needed?

[drinkypoo]

"Putting a firewall on the system it is meant to protect is like wearing a bulletproof vest on the inside." -- I can't remember.

I don't agree that it's true. It's just not a complete step. The outside firewall prevents attacks that exploit the network or filtering code, in cases in which the traffic is not permitted to reach the host. But if there is even one port that goes through, then such an attack is viable and firewalling separately has bought you nothing.

The most important means of protecting the system is to close off unnecessary ports by not attaching to the interface in the first place. Less surface means less chance for vulnerabilities. If you're not doing certain things then certain daemons can listen only on lo and not on an eth.

Re:NAT needed?

[Hatta]

This isn't about NAT, it's about firewalling (blocking ports). You can have a firewall without NAT, but apparently allowing firewalls allows NAT too. Since NAT is bad design, and as you say unnecessary, we'd like to disallow it at the protocol level. However if you do that, you can't have a firewall which is a problem for some people. IMO, firewalls are bad design too. Close the ports you don't need, and use ACLs to limit access to the ports you do.

Re:NAT needed?

[Kadin2048]

This isn't about NAT, it's about firewalling (blocking ports). You can have a firewall without NAT, but apparently allowing firewalls allows NAT too. Since NAT is bad design, and as you say unnecessary, we'd like to disallow it at the protocol level. However if you do that, you can't have a firewall which is a problem for some people. IMO, firewalls are bad design too. Close the ports you don't need, and use ACLs to limit access to the ports you do.

Sort of. By definition, a stateful firewall probably has the capability of performing NAT, but there's no reason why you'd want to, if you have enough external addresses for everything on your network.

I don't think that NAT is "disallowed at the protocol level," as much as just rendered unnecessary. You could still build an IPv6 NAT box, if you really wanted to, but it would be a bit stupid. It's like building a box that hides two Ethernet cards behind one MAC address -- sure, you could do it, but since they both already have unique identifiers, why would you want to? There's no shortage. (Okay, that may not be the best comparison in the world, but you get the idea.)

NAT is driven by a shortage of routable IP addresses. With v6, there's no longer a shortage. However, people are still going to want the security offered by stateful firewalls (NAT, in its most trivial 1:1 implementations, doesn't offer any security -- it's all in the firewall anyway), which if configured incorrectly or overzealously, could create almost as many problems themselves as NAT does currently.

However, I still think that IPv6 is a big improvement. Why? Because with v6, you have the option of not using the stateful firewall, on devices that are hindered by it, while still retaining the ability to use one and mimic IPv4 security behavior. With IPv4, unless you are wealthy enough to afford a static IP for everything in your house, you don't even have the option of exposing more than one device (per port) to the public Internet.

To me, this demonstrates that there's really no downside (besides the obvious implementation cost) to IPv6. People who just want nothing to change, can basically have nothing change. Their IPv6+Firewall network will behave just like an IPv4 one, but people who want to use the capabilities of IPv6 (for example, VoIP using SIP) will be able to, by reconfiguring their firewalls to be a bit smarter about incoming traffic.

Re:NAT needed?

[Anonymous Coward]

NAT, in its most trivial 1:1 implementations, doesn't offer any security

When people talk about using NAT, 99% of the time they don't mean a 1:1 NAT, but a NAPT as found in home routers and configurable in many midsize routers and PC operating systems.

Such a NAPT does offer security because it disallows all uninvited incoming connections and thus shields "services" running on systems inside of the NAPT from access from the Internet.

Re:NAT needed?

[MobyDisk]

Software firewalls are a non-sequitor in my opinion. It's really an added layer of obscurity.

If someone installs a firewall and say "please block port 123" I can't help but ask "Why did you open port 123 in the first place, then build a wall in front of it?" The fact that these firewalls exist just shows how stupidly the operating-systems UI is that it is so complicated to determine what apps are listening on the network, and what apps aren't.

Blocking outgoing apps is a completely different issue, and software firewall might make sense for that, if you don't trust the applications on your machine (which is a sad state of affairs anyway)

Re:NAT needed?

[Anonymous Coward]

Now, that's just stupid.

Think about it - your firewall is usually a different machine than the one the, er, less than technically savvy users, are using to run their applications on. Say one of them gets a virus or trojan that is able to exploit a hole and create a hole in the local firewall. *poof* you are toast.

With an external firewall box, you have limited your exposure, since that trojan more than likely is not going to break into that box from the outside, or even the inside, should it get in. So, it *still* can't get out to the network.

It's called "don't put all your eggs in one basket." Think a little next time...

Re:NAT needed?

[Kadin2048]

When people talk about using NAT, 99% of the time they don't mean a 1:1 NAT, but a NAPT as found in home routers and configurable in many midsize routers and PC operating systems.

Such a NAPT does offer security because it disallows all uninvited incoming connections and thus shields "services" running on systems inside of the NAPT from access from the Internet.

Sure. But what they're really describing isn't NAT, but rather the stateful firewall that's inherent in all non-trivial implementations of NAT.

Since you can take just the stateful firewall part, and use it with IPv6, there's no security disadvantage there. All you lose is the kludgy NAT parts, and in trade you gain the ability to do much more complex and useful routing -- creating various subnets with different security levels, etc. It's nothing that hasn't been going on with big corporate networks for years (those companies that have Class A blocks and can afford to give every workstation a 'real' IP still have firewalls and security policies), but now home users can have the same flexibility, if they want it.

Re:NAT needed?

[Paulrothrock]

Still doesn't mean I wouldn't want a NAT to offer a centralized location to manage my network. Right now I've got a NAT router forwarding most ports on my IP to my Mac Mini server (which has its own firewall), and a few gaming ports to my Powerbook. Managing a firewall in a single location would be a lot easier than managing a firewall on multiple devices.

And how will IPv6 affect broadband? Right now I'm only allowed one dynamic IP. Would all broadband providers be forced to monitor individual IPs across their network?

Re:NAT needed?

[pla]

If tis is true, we may not need NAT each device be it a computer, Wii, or Tivo could have it's own dedicated IP.

That works great - As long as your ISP gives you as many addresses as you want, and for free. Oh yeah, and that you trust every machine out there that wants to connect to you.

In theory, IPv6 exists in the first place to eliminat that as a problem - Everyone can have thousands of addresses, with no risk of ever running out (strange, did the echo of that come back "640k...40k...k"?)

However, given the greedy nature of most broadband providers, they almost certainly will artificially re-create the same problem, either by limiting addresses or charging on a per-address basis. And the second they start pulling that crap, we'll see NAT suddenly mature for IPv6.

Re:NAT needed?

[toadlife]

[i]"In theory, IPv6 exists in the first place to eliminat that as a problem - Everyone can have thousands of addresses, with no risk of ever running out (strange, did the echo of that come back "640k...40k...k"?)"[/i]

Actually, with ipv6 a home user would have over 18 Quintillion addresses.

Re:NAT needed?

[bunco]

Services that require secondary/back-connections are not all that common. FTP is obviously the most common but even $40 firewalls can handle it. BT doesn't count since it uses well known ports (i.e. no negotiation of which ephemeral ports to leverage). The firewalls that are present in environments which use RPC are more than capable of intercepting portmapper requests and opening ports.

Re:NAT needed?

[nschubach]

Most likely the cable providers will start charging per IP, and most of us using routers with NAT will still use routers with NAT.

Re:NAT needed?

[robwicks]

I think this analogy may, in fact, be true. However, a computer is not a human being. Putting a bullet proof shield right beneath the skin would provide protection against the things bullet proof vests normally protect against. We cannot engineer such a thing in a human, but we can in a computer. Also, let's not consider "the computer" as being the same thing as "the person." We can't just replace a brain like we can a kernel. A computer is a modular device of discrete components (hardware, various programs, etc) which is programmed to perform functions. Having a portion of it protect the rest is no crazier than having a person defend themselves against attack rather than depend exclusively on the police.

Re:NAT needed?

[drinkypoo]

A computer is a modular device of discrete components (hardware, various programs, etc) which is programmed to perform functions.

A human is a modular device of discrete components (organs) which have evolved to perform functions.

Oh sure, exchanging components in humans isn't all that easy. But it can be done.

I think it's a silly analogy because if you configure it in a certain way the firewall makes the attack surface invisible - you can't tell which ports on the system have things bound to them, because if you don't pass the firewall rules, the firewall doesn't tell you that you're not permitted to connect, it just tells you to fuck off, behaving as if that port were not just denied, but unopened.

Something under your skin doesn't hide your orifices :) and thus it's a ridiculous analogy, like most.

Re:NAT needed?

[Inner_Child]

...the firewall doesn't tell you that you're not permitted to connect, it just tells you to fuck off...

Apparently every woman I meet is a firewall...

Re:NAT needed?

[bn-7bc]

no as per rfc3177 section 3 (ftp://ftp.ripe.net/rfc/rfc3177.txt) the normal case even for home users wold be getting a 48 bit mask this means that you hac 16 bits for local subneting (128 bits - 64 (interface id) -48 (prefix) =16 bits). I know this is just recomandations bet the maximum prefix lenght is 64 otherwise the method for autoconfiguration will not work. Personaly I think that the norm will be that you recive a static /48 with youre standard contract and youre ISP will charge you exstra for a shorter prefix/multiple 48s. Why I think static will be standard: 1: easier for ISP to keep track of who has an address block in case of legal problems (Copyright infringement + RIAA) 2:no need to conserve addresses as an ISP will be asigned sufficient adressn space and it will be relativly esy for them to get exstra address space when needed. Notes: If uou dissagree with me, or I'm plain wrong, pleace tel me so but bøeace dont't mod me down unless I'm totaly off topic

Re:NAT needed?

[fishboiler]

Today, a standard firewall topology has public (routable) ip adresses on the outside (internet) and private addresses on the inside. The firewall does NAT between the networks. To allow outside access to an internal device, the firewall administrator must configure NAT mappings from public outside adresses and ports to inside addresses and ports, and firewall policies that allow the connections.

In an IPv6 environment, there will be public addresses on both outside and inside. The firewall will normally route packets (instead of doing NAT). Thus, the administrator only needs to configure the firewall policies. This can be done today if you have public IP adresses for your internal network. So it is noting new.

Re:NAT needed?

[Tony Hoyle]

If (and it's a really big if) the major providers ever support ipv6 it's odds on they'll give you *one* ipv6 address then charge for larger blocks, just like they do now. NAT will still be absolutely essential - that's why off the shelf cisco routers support NAT over ipv6 even now.

Re:NAT needed?

[carl0ski]

[quote]Also, let's not consider "the computer" as being the same thing as "the person." We can't just replace a brain like we can a kernel.[/quote] not exactly The brain can be replaced, knowledge data and skills can not be Staff turnover in some business' is enormous since you can replace people with other people. A business can sack a person and replace them. You can reinstall a computer and replace the kernel. it is difficult and timeconsuming to hire a new person with the exact knwoledge and data as the previous person it can be difficult and timeconsuming to restore a new kernel with the exact knwoledge and data as the previous kernel

Re:NAT needed?

[Urusai]

The reasons I see for using them are 1) central control of network traffic, and 2) blocking the Internet background radiation. NAT is not required for firewalls. The real problem is that so many stupid firewalls block based on port, as if you can't tunnel through any port you can open. That component of firewalling was always stupid.

Re:NAT needed?

[swilver]

I don't think I will ever trust any other appliance than my firewall to be directly accessible by anyone from anywhere. For me the point is moot, there will be NAT in my home simply because I see no reason to expose myself to potential problems. If I need to access my refrigator, I can get around my own firewall in various ways that require decent authentication.

Re:NAT needed?

[Anonymous Coward]

Even if there's an abundance of IPv6 addresses, that doesnt mean I will actually *get* these addresses for *free* on my consumer line at home, for example ;)

Re:NAT needed?

[Anonymous Coward]

But wearing a bulletproof vest on the inside is eminently sensible!

Gunshot wounds usually kill when major internal organs are physically damaged, or major blood vessels are torn open. It is pretty rare for flesh wounds to prove fatal, and in half those cases it's because of sepsis or other infection, and sometimes that can happen even if the skin is only bruised (as when one is shot while wearing a bulletproof vest on the outside).

So apart from skin damage and some blood loss, having a bulletproof subcutaneous layer, even one on the inside of the rib cage, would be much better than having none at all.

Here's a counter-quote. On NAT's similarity to Voodoo: "If you don't know it's name, you can't curse it". -- Len Bosak.

Transmission

[eldavojohn]

Request:

Obsession With Firewalls Could Hinder IPv6

*incoming request on port 9045, port reserved for new ideas*

Response: 'Obsession'?! I don't know what you're talking about.

*request identified as critical of host*
*request forwarded to port 6666*
*incoming request on port 6666, port reserved for criticism*

Response: Maybe I'm not the problem, maybe IPv6 is the problem? Shouldn't a solution to a problematic situation meet the needs of said situation, not the other way around?

*incoming request passed through network firewall, computer hardware firewall and finally rejected by software firewall, request complete*
--
Come on, this is like intercourse, sometimes girls/requests just require double or even triple bagging, the last thing you want is a virus. Some girls are regular port scanners ifyaknowwhatImean ...

Re:Transmission

[Sancho]

The problem was that NAT makes connections somewhat hard to deal with. IPV6 was designed to solve that problem. The problen now is that we realize that computers are vulnerable and need protection. IPV6 was not designed to solve that problem, and furthermore, it's not a problem which is likely to be overcome using technology or a new protocol.

Re:Transmission

[Anonymous Coward]

http://thedailywtf.com/forums/55879/PostAttachment .aspx

Caption says "Error fetching resource list from repository.

Reason:
I/O exception occured: Connection refused: I HATE YOU.

Re:Transmission

[strikethree]

The problen now is that we realize that computers are vulnerable and need protection.

Wrong. Microsoft based operating systems are vulnerable. Those operating systems are the only operating systems in existance that have ports that can not be shut down or limited to loopback addresses only.

Regardless, I am not certain how they equate controlling traffic with using NAT. They are each distinct concepts. A firewall does not necessarily imply NAT and NAT does not necessarily imply a firewall.

strike

Re:Transmission

[lnjasdpppun]

Any system accepting connections from the public internet may be vulnerable, this isn't specifically a windows problem - you can run Apache on Windows if you really want to. IPv6 makes it so all systems will be able to accept connections since there won't be any NAT to mess things up.

NAT implies firewalling, in a way, because you have to specifically tell the NAT device where to send incoming connection requests (as in port forwarding) otherwise it doesn't know what to do with them (which of the X computers in the private LAN behind the NAT gets the incoming request?) and drops the packets by default. This is what Ars is talking about, without a NAT the default process of dropping any incoming connection requests goes away too and the responsibility falls back to each of the computers on what was the pravate LAN behind the NAT box.

However I don't see why its a big problem, most OS's already come with firewalls that I assume can/will handle IPv6 so the firewall isn't going anywhere. It's just moving the firewall from a single box thats handling all internet traffic to all the systems on a network - configuration hell maybe but not an EVERYBODY PANIC situation.

Re:Transmission

[Sancho]

Wrong. Microsoft based operating systems are vulnerable. Those operating systems are the only operating systems in existance that have ports that can not be shut down or limited to loopback addresses only. I'm not sure how true that is. I'm fairly certain that it's possible to run without any services exposed, and without the Windows Firewall--not that the Windows Firewall is an issue, since the entire OS is so tightly integrated, limiting to loopback is virtually handled explicitly by setting up the firewall. It's a different paradigm from Linux.

And even then, it's still quite possible for the TCP/IP stack or network driver to have bugs which could allow system-level access. A firewall (real, dedicated, external firewall, not iptables or Windows Firewall or PF running on the machine itself) will help protect the machines. It's another layer of protection--and that's what security is all about.

Regardless, I am not certain how they equate controlling traffic with using NAT. They are each distinct concepts. A firewall does not necessarily imply NAT and NAT does not necessarily imply a firewall. In the layman's world, they're basically the same thing. It's a hardware device like a Linksys or D-Link. You and I know that they are distinct, but that's not the point.

Re:Transmission

[Sancho]

not an EVERYBODY PANIC situation. I didn't think that the article was telling everyone to panic :) It's just making the point that some of the security issues we take for granted might not be reasonable with the move to IPV6. They specifically mention the Airport Express fiasco, where IPV6 was not filtered by default, but also consider that without needing NAT, we can use dumb switches to connect multiple devices to the network connection. This exposes them all--and it's partially the point of IPV6. But it could mean that they are more vulnerable, too.

So it's not a panic situation--it's a situation where manufacturers of these devices need to take responsibility for security.

Re:Transmission

[strikethree]

Any system accepting connections from the public internet may be vulnerable, this isn't specifically a windows problem - you can run Apache on Windows if you really want to.

It would be the Apache service that was vulnerable in that instance, not the operating system itself. My point was that Microsoft continually forces its operating systems to be vulnerable to drive by attacks while with other operating systems, you get to choose your level of exposure thereby negating the need for a firewall. E.g. Mac OS X ships without the firewall turned on and yet, as shipped, Mac OS X is not vulnerable to any external attacks (except possibly to its IP stack).

Putting the Apache web server behind a firewall is rather pointless as it will then not be available for use.

strike

Re:Transmission

[strikethree]

I'm not sure how true that is. I'm fairly certain that it's possible to run without any services exposed, and without the Windows Firewall

I would be highly interested in knowing how you achieve this. How do you make port 445 not available to the outside world without a firewall? Port 135?

strike

Re:Transmission

[swilver]

I always thought that IPv6 is over the top and I also questioned the sanity of having every little device in my home directly addressable from the (hostile) outside world. Going from 32 bit addresses straight to 128 bit addresses (which increases packet overhead immensely) never sounded like a very good idea to me, let alone the fact that 128 bit addresses are incredibly cumbersome to deal with and agreed by almost everyone to be a ridiculously huge jump (more addresses than atoms in the universe or something like that?)

Perhaps I'm just a bit too conscious about these kind of things, but I think that for a lot of realtime applications protocol overhead must be kept to an absolute minimum.

Re:Transmission

[Sancho]

The below references Windows XP SP2. It may work for earlier or later versions, but that's all I have to test with.

Disabling port 445 is easy--just disable the Server service.
Disabling port 139 (another common one on Windows) is almost as easy--you have to disable NetBIOS over TCP/IP in the WINS tab of the TCP/IP advanced properties.

135 is a serious pain in the ass to disable, but it's still possible. You have to muck around with the registry.
First, create the hierarchy here:
  Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Rpc\Linkage\
  Value: Bind
  Type: REG_MULTISZ

The value of Bind is a list of network interfaces to which RPC should bind. Leaving it blank means that it won't bind to any. You can install the loopback interface and bind to it, if you require RPC for anything. However RPC still binds to all interfaces by default, unless you add another registry key:
  Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\RpcSs\
  Value: ListenOnInternet
  Type: REG_SZ

The value should be N. A value of Y (the default, assumed value) means that it should bind to all interfaces.

I ran through these steps and used nmap to test:

Firewall off:
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds

Server/Computer Browser Service Off:
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn

TCP/IP Advanced properties, WINS tab, "Disable NetBIOS over TCP/IP":
PORT STATE SERVICE
135/tcp open msrpc

And after making the registry changes and rebooting, all ports were closed.

Maybe that will help a little. I don't know how significant disabling RPC will be on a Windows box. I could still use the box for everything I do with it, however that's fairly minimal.

More information on all of this (basically, where I originally got most of this information), including references for the keys above, are at http://www.hsc.fr/ressources/breves/min_srv_res_wi n.en.html

Re:Transmission

[strikethree]

This is an interesting reply. Thank you for taking the time to come up with this information. However, it does not appear to be valid on Windows XP 64 bit edition (I have not been able to try it on the 32 bit edition yet so it probably does work there as you say)

I made the key Rpc and made a subkey called Linkage as described. I added a multi_sz value called Bind. Upon reboot, the Linkage key with its value Bind is gone. I imagine Windows is deleting it.

Stopping the Server and computer browser services also does not get rid of port 445. The services are indeed stopped, but port 445 is still open.

To restate: ports 135 and 445 are still open and available to the world and port 139 is gone. *sigh*

strike

Re:Transmission

[strikethree]

BTW, thanks for the cool link. I read it thoroughly and was able to remove all ports except 135 and 1025. 135 is being invoked by something within svchost.exe and 1025 is being invoked by lsass.exe. I am not sure why lsass needs to listen for remote connections but whatever. Killing ports should not be this painful nor this dangerous. I have been risking making my system non-bootable by playing around with dcom, rpc, msdtc, etc. I think my original point still stands. :)

strike

Re:Transmission

[Sancho]

Hi,

I installed Windows XP 64-bit edition through VMWare and saw similar results. I did manage to disable port 445 by disabling several services (setting them to Disable) and rebooting. I think all you need is Server and Workstation disabled (or at least not running) plus all dependencies, but I also had Remote Registry disabled. I'm pretty sure this is an RPC service, though, so it should be irrelevant.

I had the same results as you did regarding disabling port 135. I did a little more digging and found this page on the same site I referenced before: http://www.hsc.fr/ressources/breves/min_w2k3_net_s rv.html.fr

It has information on disabling rpc from listening on the public interface, though my cursory glance at the page didn't uncover a way to disable it completely. Run "netsh -c rpc" from the command prompt, then type "add 127.0.0.0" (not 127.0.0.1). When I did this and rebooted, port 135 was no longer showing up on my port scan.

That's not to say that you should have to muck around with arcane commands just to keep your computer from accepting connections from everyone and his brother, but this shows that it certainly does seem possible.

Re:Transmission

[Sancho]

No doubt! I completely agree that it shouldn't be this hard, and that you shouldn't risk screwing up your computer just to keep the ports closed. I'm not sure what Microsoft was (collectively) thinking in doing things this way. Probably that the firewall is good enough, and less likely to break applications which might depend upon these services.

The page I linked to in my other reply has some information on lsass, too. I didn't play around with that, as 1025 wasn't showing up in my port scan.

Glad you liked those pages--they were very useful some time ago, and I was glad to find the updated version (dated 25/03/2005, as opposed to sometime in 2002).

Defective by design?

[gstoddart]

Not to overuse the whole 'defective by design' thing, but:

'This means the IETF's efforts to keep IPv6 NAT-free in order to make protocols do their job without messy workarounds are defeated by the notion that everything should be firewalled.' If we decide to stick with firewalls in IPv6, we'll see many of the same hard-to-diagnose network problems that we have with IPv4.

So, they're saying the way to get security in IPv6 is to throw away the whole concept of firewalls and hope that the protocol won't leave us with out collective bums hanging out in the wind??

I can't see a widespread adoption of a protocol that wants to get rid of firewalls. Now, I guess it's entirely possible that the IPv6 would secure networks since I'm not really up to speed on it's details. But I'm going to need an awful lot of convincing before I put any machines onto a network without something physically between me and it.

Unless IPv6 is very different, the only way I'm going to be able to set up my own personal network (and secure it) is with NAT. I'll take 'hard to diagnose' over pwn3d any day.

This just sounds so wrong.

Cheers

Re:Defective by design?

[Detritus]

You can still have firewalls, it's just that some firewall "features" have unintended consequences.

The old-style stateless firewall will work just fine.

Re:Defective by design?

[Anonymous Coward]

So, they're saying the way to get security in IPv6 is to throw away the whole concept of firewalls and hope that the protocol won't leave us with out collective bums hanging out in the wind.

Not at all. The idea is to get rid of the hack that is NAT (as there are plenty of address to go round), and keep the firewall. However, it might not be that much of an improvement because troubleshooting a firewall router isn't that much different from troubleshooting a NAT one.

Re:Defective by design?

[drinkypoo]

The old-style stateless firewall will work just fine.

Actually, the article is saying that many protocols require connections to odd ports, and connections from random hosts (think bittorrent) so firewalling must be application-controlled.

It's similar to NAT in that both NAT and firewalling (of IPv4 or IPv6) require that you make and break rules on the firewall to allow traffic to get where it needs to go.

Of course, you could just firewall all privileged ports... But then you'd still be leaving things open for inward connections to trojans with a daemon.

Re:Defective by design?

[gstoddart]

Actually, the article is saying that many protocols require connections to odd ports, and connections from random hosts (think bittorrent) so firewalling must be application-controlled.

But, who is going to trust an application to determine network policy? The first malicious application to come along will bork the whole system, won't it? I mean, 'random' hosts is the perfect invitation for badness.

Maybe I'm just (once again) demonstrating my ignorance of such things, but this sounds like it will introduce more problems than it fixes.

Cheers

Re:Defective by design?

[drinkypoo]

But, who is going to trust an application to determine network policy? The first malicious application to come along will bork the whole system, won't it? I mean, 'random' hosts is the perfect invitation for badness.

It's worth mentioning that there is little or no reason for most people to run these programs at work, with certain notable exceptions like FTP (Which should just be allowed to fucking die already) and Bittorrent (which can be configured to use a single port.)

Maybe I'm just (once again) demonstrating my ignorance of such things, but this sounds like it will introduce more problems than it fixes.

It's not introducing a problem! This problem exists today with IPv4 whether you are using NAT or just firewalling!

What they're saying is that IPv6 is not going to fix a problem with the logistics of firewalling that is already with us today.

Re:Defective by design?

[Anonymous Coward]

with certain notable exceptions like FTP (Which should just be allowed to fucking die already)

What would you suggest replacing FTP with? I do agree that the whole control/data port thing is just fucking weird, but passive FTP at least makes it sane again.

Somehow I get the feeling you're going to say "WebDAV".

Re:Defective by design?

[Tuoqui]

I do not believe they are saying that we should have NO FIREWALLS at all. I think the idea is to have more permissive firewalls since with that many IP addresses available in IPv6 the odds someone will be RANDOMLY scanning and hitting something for someone is so remote that it is almost a guarantee that they're specifically looking for you.

The current scanning networks and such works because of one thing, you can almost count on hitting some IP addresses at any given block on the IPv4 network. Also because like 90% of computers are running windows you can probably scan for vulnerabilities and attack almost as quickly.

Re:Defective by design?

[Kadin2048]

I really don't think the problem is as big as it's being made out to be.

The advantage to IPv6 is that you can have more fully routable addresses, to the point where there wouldn't be any NAT anymore -- you might still have dynamically assigned addresses, but they'd still be fully routable across the entire network. This makes firewalling a lot simpler, because you can have more than one DMZed device.

Devices which are known to be relatively secure and are designed to sit out in full view of the public -- for instance, maybe a VoIP appliance that by definition has to accept incoming traffic, but rejects everything else (but which needs lots of ports and can't tolerate NAT or much 'dumb' firewalling), could be easily put into its own DMZ without compromising the rest of your LAN. Right now, with IPv4 and only one shared IP address per household, this is fairly difficult -- all firewall rules need to be port-based. With IPv6, you can also do more complex address-based routing.

So, let's say you have a network consisting of four devices and an IPv6 firewall; you have two highly insecure Windows boxes (for whatever reason) which aren't designed to and consequently cannot safely be exposed to the world, plus a hardened BSD machine which can have certain ports exposed (say, for email and SSH), and an VoIP appliance which needs to be able to make whatever connections it wants. You configure the firewall (which all traffic passes through) to not perform any packet filtering on the VoIP appliance's address, effectively leaving it outside the perimeter. (Hopefully the manufacturer of the appliance knows what they're doing. But, to be safe, you could set it up so that traffic from it doesn't get let in to the firewalled zone, so someone couldn't compromise it and use it to get in to the rest of your network.) The BSD machine's address gets only the necessary ports opened, with everything else to it automatically rejected. And the Windows boxes are totally firewalled, with all incoming connections rejected unless a port is specifically requested open.

The firewall required to do this isn't any less complex than a current NAT/stateful-firewall, but it provides several advantages. Rather than having only one externally-facing address for the entire LAN, and routing traffic based on the port or TCP connection, you can just route based on the IPv6 address, and create all sorts of (in)flexible rules based on how much trust you have in the destination device, which can include creating further subnets that are isolated from each other, for security purposes.

IPv6 isn't "insecure," in fact I think its wide adoption will greatly enhance end-user security, once people start figuring out how to work with it, and the Linksys and Netgear-type manufacturers start building inexpensive boxes to do the job.

The main difference between v4 and v6 is that with v4, there's a clear demarcation between "LAN" and "WAN." With IPv6, this isn't quite as true; rather than thinking of security in terms of castle walls, you need to use a more fluid metaphor. Everything in your house is part of the "WAN," in terms of addressing, but parts of it may be more secure than others.

Re:Defective by design?

[Tofystedeth]

Unless you had an IPv4 address mapped to IPv6 using a method supposed to prevent breakage of existing DNS info etc... Then all they have to do is modify their scan to simply scan the IPv4 space in IPv6.

Re:Defective by design?

[Lord Ender]

In the tech world, you must adapt or die.

Your reasoning for using NAT seems to be based on dogma and tradition, not actual... reason.

So it seems you have selected "die." Good luck with that, dinosaur!

As a security pro, I can't WAIT to see the death of NAT. I am concerned that some of the older people around here will make it a lot harder than it needs to be out of an irrational fear of change and (gasp) having to learn something new :-(

Re:Defective by design?

[Azghoul]

This was a really nice explanation. Thanks a lot.

I'm a little confused about how someone would be able to go about building a DMZ using IPv6 - just connect it through a different switch and don't allow traffic to go from it to your "internal" machines?

Re:Defective by design?

[gclef]

Right...so, a VoIP phone (running SIP or H323, which do this sort of dynamic port-allocation) is not something useful for work?

Re:Defective by design?

[Penguin Follower]

How about sftp? Works great for me. ;)

Re:Defective by design?

[arodland]

Not half as useful as one using IAX would be, because it doesn't pull all of the stupid useless shenanigans that SIP does, and is therefore firewall-friendly. :)

Re:Defective by design?

[Niten]

No, he isn't saying that we should allow applications to control our firewall settings (as is already done by default in many consumer NAT routers, incidentally, with UPnP). What he's saying is that modern firewalls, as a result of the complexities introduced by NAT and other technologies, need to think on the application level (OSI layer 7) rather than network and transport levels (OSI layers 3 and 4).

This is already achievable using, e.g., Linux's L7-filter module in iptables (and is part of the reason that I use a Debian box for my firewall/router), but is rarely seen on any but the most expensive of consumer-oriented NAT routers.

Re:Defective by design?

[gstoddart]

In the tech world, you must adapt or die.

Your reasoning for using NAT seems to be based on dogma and tradition, not actual... reason.

So it seems you have selected "die." Good luck with that, dinosaur!

No. That's not true at all. You're just being a dick for the sake of it, and you probably know it.

I'm asking for clarification of how things work relative to my own understanding. I'm not wedded to NAT based on anything -- I'm asking based on my understanding of how it works, and the fact that I'm aware that I have an incomplete understanding.

As a security pro, I can't WAIT to see the death of NAT. I am concerned that some of the older people around here will make it a lot harder than it needs to be out of an irrational fear of change and (gasp) having to learn something new :-(

And I can't wait until some of the younger people around here stop being condescending dickheads just to sound cool and think they know it all. You're free to make your own assumptions about people, but, please, try not to drag the level of discourse around here any lower than it already tends to be.

I don't have an irrational fear of change, or learning something new. I'm trying to figure out what the article is saying -- the initial reference to being "obsessed with firewalls" to me sounds like people are advocating the wholesale removal of firewalls, or that we should be leaving firewall rules up to applications. That sounds bizarre to me.

I am not a security pro, I'm trying to further my understanding of how IPv6 affects this landscape -- IPv6 has been 'just around the corner' for widespread adoption about as long as Linux has been 'almost ready for the desktop'. As such, I've taken to ignoring it since it doesn't seem to be going anywhere at any pace that I can tell except in academia.

The stuff in the summary just seemed a little odd, and I asked a question hoping that someone could shed a little light, and maybe enlighten a few people. But, hey, if you want to reduce the whole thing to childishness, then neener neener to you too! :-P

Cheers

Re:Defective by design?

[Kadin2048]

I'm a little confused about how someone would be able to go about building a DMZ using IPv6 - just connect it through a different switch and don't allow traffic to go from it to your "internal" machines?

Basically, it's just like an Ethernet VLAN, except it would be as part of a router, not a switch, because you're one level higher on the OSI model. (Ethernet is Layer 2, IP is Layer 3.) But fundamentally it's a similar idea; a subnet is really just a Layer 3 VLAN. (In actuality, I think on most networks there is a 1:1 relationship between Ethernet MACs and IPv6 addresses, so the difference between routers and switches will probably become even more nuanced.) But it's not hard to set up, it's just a matter of configuring the firewall-box's routing table appropriately. (Which in a consumer appliance would be set up already, probably with a clearly marked plug on the back for them to attach their VoIP ATA into.)

Basically you could just tell your home-router to route all traffic destined (based on the IPv6 address) for your VoIP box directly to its destination, unfiltered, but also to not treat traffic coming from that VoIP box any differently from traffic coming from anywhere else on the net. It would effectively be walled off in its own logical network. Someone who compromised it would still be able to use your WAN connection to send out viagra spam, but they wouldn't have any access to the rest of your network, any more than they already do from the outside.

Re:Defective by design?

[drinkypoo]

What would you suggest replacing FTP with? I do agree that the whole control/data port thing is just fucking weird, but passive FTP at least makes it sane again.

the problem with passive FTP is that many many FTP servers do not support it.

Like the sibling, I would probably vote for sftp; encrypted, tunneled...

I've never gotten WebDav to work :P

Re:Defective by design?

[Gerald]

I see this "IPv6 will make scanning too hard" idea presented each time IPv6 is discussed on Slashdot. This goes against pretty much all experience I've had with telephony, cable, and ISP provisioning -- when addresses are doled out, they're doled out in evenly-spaced, predictable sequences. It also assumes that the state of the art in scanning technology won't advance.

When IPv6 does see widespread deployment I'd be interested to see how soon address space scanning optimization papers start showing up (if they haven't already).

Re:Defective by design?

[drinkypoo]

Right...so, a VoIP phone (running SIP or H323, which do this sort of dynamic port-allocation) is not something useful for work?

It's useful, but ideally it would be used only on the local network, or through some sort of gateway.

It's worth mentioning that it's not necessary for it to do dynamic port allocation, the whole idea is silly, and it should never have been handled in that fashion.

Re:Defective by design?

[Kadin2048]

I think the idea is to have more permissive firewalls since with that many IP addresses available in IPv6 the odds someone will be RANDOMLY scanning and hitting something for someone is so remote that it is almost a guarantee that they're specifically looking for you.

No. I don't know of any non-clueless person who is pushing IPv6 and claiming that the address space, in and of itself, is a security enhancement. That's just wrong and bad.

Just think -- every time you go to a website, that server has your IPv6 address. If you're depending on the address for security, an attacker could just harvest the addresses from various websites and then use them to start attacking. (And if they got into the logs of a popular web site they'd have millions or billions of probably-valid addresses to work with.)

That's not security, and it's not why IPv6 is a good idea. IPv6 lets you have many more public addresses -- which are not secret -- and define good security policies based on them, so that you don't have to have a one-size-fits-all, lowest-common-security-denominator-wins policy for your entire LAN. (Which is pretty much how most home networks are now -- if you have a few insecure Windows boxes on the LAN, you need to tighten up the whole thing, since you can't really create multiple subnets with different security policies when you only have one outside-facing IP.) This way you can have hardened devices either out in public or with very permissive firewalls, and insecure devices behind tougher firewalls, without compromising each other.

No reasonable person would ever depend on the length of the address field as a security method. All security policies have to be based on the assumption that the attacker will know the address of the machine he wants to attack and what services it is running, and IPv6 allows for this easily.

Re:Defective by design?

[Znork]

"when addresses are doled out, they're doled out in evenly-spaced, predictable sequence"

v6 adresses, as a general rule, arent doled out. You get a routed /64 subnet, then you autoconfigure/assign each device on your 64bit subnet. Scanning a 64bit address space means you're scanning about err... 18 quintillion addresses (eh, bigger number than I know my prefixes)? Sure, it's a bit more predictable with internal subnetting and certain predictable parts of mac adresses (which could trivially be depredictableized), but it's a prohibitively more difficult problem, particularly if you're assuming response times and trying to avoid getting noticed, which you probably would be if you were flooding an internet connection with several trillion connection attempts per hour.

Re:Defective by design?

[Gerald]

The point I'm trying to make is that there is less randomness in IPv6 addressing than most people assume. Problems that start out "prohibitive" (such as DES/WEP cracking and MD5 collisions) tend to become less so over time.

Re:Defective by design?

[asdfghjklqwertyuiop]

Unless IPv6 is very different, the only way I'm going to be able to set up my own personal network (and secure it) is with NAT. I'll take 'hard to diagnose' over pwn3d any day.

You can't secure your network (IPv6 or v4) very well at all with NAT alone. A firewall will secure your network just as well with or without NAT.

Conceptually, NAT just changes the addresses and port numbers on packets. The firewall is what decides wether or not a given packet can pass. They are two different things and can be separated (both in theory and practice).

Re:Defective by design?

[Lord Ender]

Childishness hasn't truly begun until we start mentioning alleged encounters with each other's mothers.

Say hi to the old gal for me, will ya?

Re:Defective by design?

[19thNervousBreakdown]

WebDAV is ridiculously easy in both Apache and IIS. Not sure what you were trying to set it up in, but if it was either of those, try again, just not so hard.

Re:Defective by design?

[Anonymous Coward]

Oh sure, getting the WebDAV server set up is easy. Did it in three minutes with Apache.

Finding a WebDAV client that isn't bat-shit insane is the hard part.

For those of us who don't want to transmit all our data in the clear and want to use WebDAV over HTTPS? Forget it. Not the slightest chance in hell. Again, the clients are just fucking useless.

Re:Defective by design?

[Anonymous Coward]

quite true - security through obscurity is not enough to rely on, but it helps a little, and security through many layers is a good thing.

I can think of one good security idea about having a lot of addresses, you can attach a server to several of them that will firewall anyone who attempt to connect. Imagine if you had a whole set of IPs to yourself, if you never, ever used one you could assume that anyone who did try to connect to it was up to no good and needed banning. That kind of honeypot would be ok, but anyone that tried to connect to 10 IPs in a set amount of time would definitely be up to no good and be worth an automatic ban.

Re:Defective by design?

[evilviper]

So, they're saying the way to get security in IPv6 is to throw away the whole concept of firewalls and hope that the protocol won't leave us with out collective bums hanging out in the wind??

NO!

Firewall != NAT

NAT != Firewall

Please move along.

Re:Defective by design?

[drinkypoo]

Oh sure, getting the WebDAV server set up is easy. Did it in three minutes with Apache.

Well, maybe my problem is that the clients I was trying to use are idiotic, but I tried two different WebDAV tutorials with Apache2 and never got it to work correctly.

Maybe I'm just a moron (I'm sure lots of you think so, but you can bite my hairy white ass) but I followed the instructions carefully and still never got good results. Since it wasn't actually important, I gave up.

Re:Defective by design?

[gstoddart]

Childishness hasn't truly begun until we start mentioning alleged encounters with each other's mothers.

Say hi to the old gal for me, will ya?

*laugh* OK. Give yours a kiss for me as well.

Cheers

Re:Defective by design?

[GlL]

Hi,

I work for an ISP. Here is a random jumble of my thoughts in reference to some of what has been discussed in this thread.

CLECs have been mandated to run IPv6 by year end 2008.

I think that our best bet will be to run IPv4 internally and IPv6 externally, at least until we have a better handle on how IPv6 runs in the wild. Then when we understand the quirks we can bring it inside our networks.

Setting up IPSec for every transaction you make would be an overhead killer. Think of the dial-up users that still exist out there.

The idea of there being so many addresses that you can't possibly hit them at random is not something I want to base my customer's or my security on. All you would have to do is compromise one ARP table to get a list of other targets. The way routing works isn't really going to change either, so a routing table would work just as well.

Anyway, I want an SPI firewall that places a boundary between my internal network and the internet. The IP address shortage is not the only reason that those boundaries exist. I honestly don't care if there were to be an infinite number of addresses. I have to think in terms of worst case scenarios because I will lose customers if I don't. Information is the most valuable commodity in our world today, and as long as that is true firewalls MUST be set to the maximum functional level of restrictiveness.

Re:Defective by design?

[dcam]

Yeah, I have no reason to download linux ISOs for the linux servers I admin while I am at work. Or send files to another person at work in a work conversation over IM.

Re:Defective by design?

[drinkypoo]

Yeah, I have no reason to download linux ISOs for the linux servers I admin while I am at work.

(-1, PoorReadingComprehension) - I gave bittorrent as an example of an exception, and besides, bittorrent doesn't actually have this problem because it can be configured to listen on another port. Unless you're talking about FTP, in which case you're just stupid.

Or send files to another person at work in a work conversation over IM.

If you're doing IM with someone at work, you should be using an internal server, so that your work-related correspondence cannot be tracked by the IM servers in any way. Also, all respectable IM clients support proxies.

Just another fine example of the quality of your average comment...

Re:Defective by design?

[syousef]

It's worth mentioning that there is little or no reason for most people to run these programs at work, with certain notable exceptions like FTP (Which should just be allowed to fucking die already) and Bittorrent (which can be configured to use a single port.)

Spoken like a man truly out of touch!

First of all making such a blanket statement about what people do and don't need at work, presumably based only on your own experience is totally asinine. Even with lots of research deciding what everyone in every job does or does not need is not an easy thing. Let me guess you're the kind of system administrator that likes to lock down an IT worker's policies so that they no longer have an admin account, then wonder why the get upset at you.

Secondly what kind of fugknuckle suggests that FTP should "be allowed to fucking die already". Do you realise there are systems out there that don't even have a decent implementation for SFTP? (Hint: Look up VMS) Realise that there are systems that would need to be reworked and re-tested if you got rid of internal FTP? I'm not saying they shouldn't be migrated to something more secure in most cases, but not catering for such systems is not an option. IPV4 interoperability is going to be critical for the forseeable future.

How the FUCK does the parent post get moderated as insightful in a community of IT professionals?

Re:Defective by design?

[drinkypoo]

First of all making such a blanket statement about what people do and don't need at work, presumably based only on your own experience is totally asinine.

Don't make assumptions. It will only get you into trouble.

Even with lots of research deciding what everyone in every job does or does not need is not an easy thing. Let me guess you're the kind of system administrator that likes to lock down an IT worker's policies so that they no longer have an admin account, then wonder why the get upset at you.

Actually, I'm the kind of administrator who likes to do things the secure and efficient way.

Sometimes that means locking things down. Sometimes it means just reimaging often.

Secondly what kind of fugknuckle suggests that FTP should "be allowed to fucking die already".

What a colorful insult, child. But the fact is that FTP is a gigantic pain in the ass and instead of continually being "updated" to (almost) fit the needs of people today, it should have been abandoned and replaced long ago.

Do you realise there are systems out there that don't even have a decent implementation for SFTP? (Hint: Look up VMS)

VMS is over and OpenVMS is a farce by all accounts. Sorry if I don't have sympathy for those stuck in the dark ages. (VMS did lots of wonderful things that no one else did back in the day, but now other people do them.)

Realise that there are systems that would need to be reworked and re-tested if you got rid of internal FTP?

Really I'm not suggesting that we make it go away entirely - I mean, last I checked I still had a telnet binary pretty much everywhere. It's still good for testing.

But I am suggesting that we should have long ago supplanted it and whiny people like you who complain that they will have work to do if progress continues are the primary reason why we haven't.

I'm not saying they shouldn't be migrated to something more secure in most cases, but not catering for such systems is not an option. IPV4 interoperability is going to be critical for the forseeable future.

How did IPv4 even get involved in this conversation? Do you even know what we're talking about?

How the FUCK does the parent post get moderated as insightful in a community of IT professionals?

I assume it's because today the moderators have a pulse and two neurons to rub together.

Re:Defective by design?

[Tony Hoyle]

NAT adds an important layer of security to the firewall - you can't tell what machines are behind it. Even how many, much less what their address ranges are.

A NAT box on its own will provide an effective firewall (provided it's coded to not allow inward routing, which it will be unless the programmer that designed it is totally retarded). It never is on its own, of course.. if you implement that you might as well have a stateful firewall because it's very similar code.

Re:Defective by design?

[Gareth Williams]

Of course, you could just firewall all privileged ports... But then you'd still be leaving things open for inward connections to trojans with a daemon.

When trying to come up with a good design for your network security, do you really think you should be worrying about protecting machines that are already compromised?

By the time there is a trojan on the machine, you have already lost. Game over. Why bother blocking incoming connections to the trojan? What would be to stop the trojan from placing it's own outgoing connection to the attacker's network?

Please don't suggest blocking miscellaneous outgoing connections either :) That is the path of band-aids. Only madness lies there.
("we'll only allow certain protocols!" -> "the trojan can simply tunnel over an allowed one, like http". "ok, we'll run the firewall on the actual machine, and only allow specific applications to initiate network connections" -> "hello? the trojan already owns your machine." ... etc etc. I'm sure you get the idea).

Re:Defective by design?

[syousef]

Don't make assumptions. It will only get you into trouble.

You mean like your assumption about what people do and don't need at work? Pot. Kettle. Black.

Actually, I'm the kind of administrator who likes to do things the secure and efficient way.
Sometimes that means locking things down. Sometimes it means just reimaging often.

Translation: If I think a user has any more power than they absolutely need to do their job, I'll take that away from them. The power I've been given to secure the network trumps their efficiency, their sanity and their right to be treated like a human being who may actually shock horror take a 5 minute break and do something that for their own personal reasons.

What a colorful insult, child. But the fact is that FTP is a gigantic pain in the ass and instead of continually being "updated" to (almost) fit the needs of people today, it should have been abandoned and replaced long ago.

Guess what. This is the real world. You can't just magically replace systems that are well entrenched, do their job and are rock solid stable. I'd love to see you come to my workplace and suggest VMS be replaced. That's only what our team has been doing for the last 4 years or so. You have no freaking clue about enterprise systems if you think that everything's a simple link easily replaced. ...and I'm the child? Honestly if you're going to act like a cross between a network nazi and a grizzly bear, expect people not to like you - after all you're not payed to be liked and quality of the workplace probably doesn't have much meaning to you. Your entire world view and your views about being an admin are backward. You're there to serve the end users as well as management. You should only take away things they need or want if you're left with no other choice, not as a first reaction. The whole "lets lock down anything not absolutely necessary" philosophy might be lovely from a paranoid security admin point of view, but you forget that the proliferation of the modern computer came about because it is an enabler. Anything you do to make it a burden to use the computer systems is an anethma.

VMS is over and OpenVMS is a farce by all accounts. Sorry if I don't have sympathy for those stuck in the dark ages. (VMS did lots of wonderful things that no one else did back in the day, but now other people do them.)

Oh yes, if it's not shiny and new lets throw it out and start again. Your sympathy is not wanted where I work, nor is that attitude. You have no concept whatsoever of what systems are out there still running. However please continue this way. When I have experience with a wide gamut of systems, and you're stuck with the most common one, I'm the one that'll pick up the well paying job, while your arrogant ass whines about why no one likes you (because you keep limiting what they can do, and increasing their workload, how tough your job is, and how you should be paid twice as much.

Really I'm not suggesting that we make it go away entirely - I mean, last I checked I still had a telnet binary pretty much everywhere. It's still good for testing.

But I am suggesting that we should have long ago supplanted it and whiny people like you who complain that they will have work to do if progress continues are the primary reason why we haven't.

You're talking out of your backside. You don't test a different system to what you implement in prod. You get them as close as possible. I'm not complaining that I have work to do. I'm a developer and I like having a stable job. Your inability to comprehend that it can take a very long time to replace a system however is astounding. Good luck with that. In the meantime if I have to work around one more know-it-all sysadmin that doesn't have a clue how things really work I'm going to vomit. Thing is it's amazing how in previous jobs I've seen such sysadmins fall out of favour once they tread on a senior manager's toes. There's one I can think of that was forced out altogether.

I assume it's because today the moderators have a pulse and two neurons to rub together.

Two neurons definitely sounds about right.

Re:Defective by design?

[Znork]

True, and there will be other attack forms (like scanning traffic, listening for dhcp solicitations, listening for other broadcasts or simply setting up honeypots to collect ip addresses like spammers collect mail addresses).

Actual network probes will remain prohibitive tho; it's not a problem of cpu capacity, it's a problem of actual time (you have to wait for responses) and traffic amounts. Apart from broadcast attacks, you simply cant do it faster or less noticable no matter how fast your hardware gets. It works when half the adresses are occupied, but when one in a million is, there are simply much better ways to get more adresses.

Re:Defective by design?

[swilver]

IMHO firewalling should never be application controlled. What's the point of a firewall when random program X can just poke a hole into it? When I see BitTorrent asking to listen on a port, then I will give it permission via a 3rd party program I trust (my firewall). If I say "NO", then there is no recourse for that program, it simply won't get access, period. I should be in control, so if I want to have a program working optimally, I can weigh the risks of having the application being accessible from the outside world

You wouldn't believe the amount of applications these days that phone home, literally every major application tries to access the internet periodically (be it to check for updates, check if your registration is valid, or to send over all your personal surfing habits and credit card info). Adobe PDF Reader is good example. I open a PDF, and the program wants to access the internet... what for? To annoy me with updates I don't need (if it ain't broken, don't fix it)? I don't think so.

Re:Defective by design?

[evilviper]

NAT adds an important layer of security to the firewall - you can't tell what machines are behind it. Even how many, much less what their address ranges are.

It takes precisely one packet to discover the number and (private) addresses of machines behind a NAT. The level of obscurity NAT provides is trivially small.

A NAT box on its own will provide an effective firewall (provided it's coded to not allow inward routing, which it will be unless the programmer that designed it is totally retarded).

Routing packets and doing NAT are two entirely separate things, and I have NEVER seen a single system that would do NAT but would not otherwise route packets (inward) without explicitly using a stateful firewall. From Cisco routers, to Windows/Linux/BSD, absolutely none of them work in the "secure" way you think NAT does. Indeed, such a form of NAT that otherwise disallows regular routing would require burying the NAT code deep inside the kernel, which is decidedly impractical.

Re:Defective by design?

[drinkypoo]

When trying to come up with a good design for your network security, do you really think you should be worrying about protecting machines that are already compromised?

No, of course not, I think we should just let them alone, and just let our systems become more and more infected.

By the time there is a trojan on the machine, you have already lost. Game over. Why bother blocking incoming connections to the trojan? What would be to stop the trojan from placing it's own outgoing connection to the attacker's network?

Perhaps you are unaware that computer programs don't write themselves? It's kind of a basic tenet of computing theory. There have been numerous trojans which do not open an outward connection, instead simply making the system available.

In addition, you could institute a restricted egress policy, allowing the user to make exceptions, and then it would actually do you some good. I realize this isn't what you want to hear, but I think making the user partly responsible for the security of the system is a good thing. Also, if the firewall runs as root (or equivalent) and simply asks the user what to do through a secure facility, then a trojan running as the user will not be able to bypass it.

Re:Defective by design?

[drinkypoo]

Translation: If I think a user has any more power than they absolutely need to do their job, I'll take that away from them. The power I've been given to secure the network trumps their efficiency, their sanity and their right to be treated like a human being who may actually shock horror take a 5 minute break and do something that for their own personal reasons.

Let me give you a more accurate translation: If I think that the user has too much power for me to be able to do my job, then I'll take that away from them. The responsibility I've been given to secure the network trumps their self-assumed right to do whatever they want on hardware that belongs to the company, and time when they are on the clock.

They can take a five minute break any time they want as far as I'm concerned. But they don't have any right to use the company computers to do it. If they can do it in a way that doesn't compromise security, then I don't care if they use the equipment. At that point, it is not my problem. But [when I am working as an admin] I have been hired to secure the network, and that is what I will do.

Guess what. This is the real world. You can't just magically replace systems that are well entrenched, do their job and are rock solid stable. I'd love to see you come to my workplace and suggest VMS be replaced. That's only what our team has been doing for the last 4 years or so. You have no freaking clue about enterprise systems if you think that everything's a simple link easily replaced. ...and I'm the child?

Actually, I have an excellent clue about intelligent design in which everything is a simple link easily replaced. I also have the experience to know that it's not always easy. Sometimes, some idiot that came before you did something amazingly stupid that makes it horribly hard to get away from their poor decisions. But it doesn't mean that you shouldn't do it, because someday their poor decisions will bite you in the ass. In fact, it's part of your job.

Your entire world view and your views about being an admin are backward. You're there to serve the end users as well as management. You should only take away things they need or want if you're left with no other choice, not as a first reaction.

I don't know on what basis you make the assumption that the first thing I do is wander around locking things down and taking things away, but I'd appreciate it if you would go fuck yourself.

Why don't you stop making your fucking stupid assumptions about me? You obviously don't know one fucking thing about me.

Oh yes, if it's not shiny and new lets throw it out and start again. Your sympathy is not wanted where I work, nor is that attitude.

As the systems age and become less popular it becomes more and more difficult to support them, and they consume more and more of your time and other resources (often monetary ones.)

Your inability to realize this fact is pathetic.

Re:Defective by design?

[syousef]

Let me give you a more accurate translation: If I think that the user has too much power for me to be able to do my job ...and then later...

As the systems age and become less popular it becomes more and more difficult to support them, and they consume more and more of your time and other resources (often monetary ones.)

Your inability to realize this fact is pathetic.

Just what the fuck do you think your job is? You've been hired to support those aging pain in the ass systems. If it was easy there wouldn't be a dedicated full time position. The business doesn't employ you to only look after the shiny and new. All I can say is thank goodness you're not my sysadmin. You're clueless.

Actually, I have an excellent clue about intelligent design in which everything is a simple link easily replaced. I also have the experience to know that it's not always easy. Sometimes, some idiot that came before you did something amazingly stupid that makes it horribly hard to get away from their poor decisions.

Hindsight is 20/20. Sometimes that incredibly idiotic thing was done for good reason, sometimes not. Walking away from a system or treating it as second rate because it's old is immature. All that matters is how it serves your employer AND the users. If you're making the user's life a misery you're not doing that.

I'm wasting my breath. Good day to you.

Translation

[Zarhan]

"Today we learned, that lots of people who have thought of NAT as a security mechanism, are getting a hit with cluebat when they find out that the IPv4 NAT also implements a stateful firewall as a byproduct. Since there is no NAT with IPv6, you only have to implement stateful firewall without address translation."

Sigh.

This is a non-issue.

What IS an issue are the new IPv6-specific things related to security. You cannot do a network scan anymore since even a /64 is a huge address space to scan and so on. The presentation I watched at IETF Prague was quite interesting: http://www3.ietf.org/proceedings/07mar/slides/v6op s-1/sld1.htm

There are some implementation issues, such as anycast addresses and stuff like that you need to take into account.

However, this "getting rid of connectivity issues due to no longer having to NAT" has NEVER been expected by anyone who knows even a bit about networking. Because we're not returning to an un-firewalled world.

Re:Translation

[AKAImBatman]

However, this "getting rid of connectivity issues due to no longer having to NAT" has NEVER been expected by anyone who knows even a bit about networking. Because we're not returning to an un-firewalled world.

Thanks for clarifying that. I had a similar thought looking at the summary. I may have forgotten nearly everything I knew about IPv6, but it seems to me that a router is a router is a router, even in v6. If your router checks the traffic (like a good firewall would do) and blocks unauthorized incoming ports, then what's the issue? You're still routing IPv6. You even have the advantage of having your internal machines directly exposing their own IP addresses. The only difference is that the network area between your machines and your router is a controlled zone where only the traffic you want to enter your network will enter.

I just don't see what the big whoop is about.

Re:Translation

[Zarhan]

And I linked the wrong presentation. I meant this one:

http://www3.ietf.org/proceedings/07mar/slides/v6op s-6/sld1.htm

"Observations of IPv6 firewall and IDS".

Sorry about karmawhoring, but I'm at karmacap anyway.

Re:Translation

[LehiNephi]

Please forgive a question from a networking newbie. What if my ISP wishes to restrict the number of computers I connect to the internet at home? Some behind-the-times ISPs still don't allow you to use more than one machine over your connection. Currently, NAT is a very simple way to get around that restriction. Does the transition to IPv6 affect that in any way?

Of course, if an ISP is decent enough to move to IPv6, they're probably smart enough to allow multiple addresses per account.

Re:Translation

[ealar dlanvuli]

You can simply run an ipv4 nat as you always have. Then at the nat, switch to ipv6 before sending off to that other network that is 'teh internets'.

Sean

Re:Translation

[Raphael]

However, this "getting rid of connectivity issues due to no longer having to NAT" has NEVER been expected by anyone who knows even a bit about networking. Because we're not returning to an un-firewalled world.

There are also some features of NAT that I would like to keep even when using IPv6, the main one being the ability to hide the topology of my networks from the outside world. So in a way, I do want to have some connectivity issues.

For example, I currently maintain a firewall and NAT box that has a pool of several public IP addresses (Internet access) on one of its interfaces, and 3 additional network cards connected to different networks. Each of these 3 networks contains a number of machines and some servers for various protocols that are mapped to some of the public IP addresses. One of these private networks is rather open (with protocols such as NIS and NFS used by most hosts) and another one is rather secure (no host trusts any other host on the same subnet). I do not want to allow an external attacker to guess on which network a given server could be. Maybe this extra level of security through obscurity is not really necessary, but I want to maximize my chances in case of an attack (e.g., zero-day exploits). Some services that I mapped to an external IP address and port may go to a server on one network, while the same IP address but a different port may go to a different network. I do not want to reveal too much information about the topology of my networks, that's why I like NAT.

NAT causes some connectivity issues, but I consider some of them as features, not problems. Oh, and I know that some people claim that the network hiding brought by NAT is just some false security and that IPv6 with its much larger address space will also make it difficult to scan hosts on a network. But that's not the point here: hiding the topology is just one of the many layers of security that I use, and the larger address space of IPv6 will not prevent some information from being disclosed in routing table updates, etc.

Re:Translation

[im_thatoneguy]

Yeah because 64+ bit email addresses have been a hugeeee help in combating spam.

I see it as a hopeless cause. If there is an easy way to access a device, there is an easy way to find a device. Unless of course you put a password on the DNS redirect.

Sure your Xbox might not have a DNS because all of the interfacing is under the table but how long until your nice static IP address is on the "black market" just like a credit card #?

Re:Translation

[AKAImBatman]

Does NAT really offer that much better security than a Dark-Net implementation? I mean, if you simply don't allow any incoming connections to the "dark" area of your network, then the only thing that the Internet as a whole can divine is that some computers from inside the Dark Net are accessing resource X using their own IPv6 IP. Since every computer on your network is unlikely to access the same addresses, this gives potential attackers nothing more than a glimpse of a few computers behind the firewall. Certainly not the sort of complete information that a port scan would find them.

Re:Translation

[nine-times]

I think the GP is acknowledging that it doesn't offer much, but it's not clear that it won't protect you at all. I agree that good security is layered, and right now NAT allows a layer of obscurity by not allowing others to discern where traffic is coming from or where it's going.

Re:Translation

[Anonymous Coward]

What IS an issue are the new IPv6-specific things related to security. You cannot do a network scan anymore since even a /64 is a huge address space to scan and so on.

This provides absolutely no security!
Even when I cannot scan a network, it is still trivial to gather valid addresses on that network. So the hosts must be protected against abuse from the outside anyway.

Re:Translation

[Raphael]

Does NAT really offer that much better security than a Dark-Net implementation?

They do not really address the same issues. First, this is not only NAT that provides the added security, but the fact that I use several disjoint networks behind the NAT box (think about DMZ + private network, except that I have more than one DMZ) and also the fact that there is no easy way for an attacker to guess the mapping between public IP addresses and private addresses in one of these subnets.

As I wrote in my previous comment, these networks contain several servers. Most of these servers are public and are intended to be accessible by almost anybody, so darknets are not really appropriate in this case.

The kind of scenario that I am trying to prevent or make more difficult by using NAT is the following: some of these servers have "interesting" contents on them and could be juicy targets for some attackers (no, I'm not talking about pr0n here but about some company internal information). These servers are usually well protected and have only one or just a couple of services exposed to the outside world (e.g., HTTP). But other servers may not be so well protected because they run experimental code for public testing or demonstrations, or simply because they run a larger number of services that may be vulnerable to zero-day exploits. If one of these "weaker" servers is compromised, I do not want it to be used as an intermediate step to launch an attack on other servers on the same network (behind the firewall). That's why I like NAT: it allows me to run the servers in different networks with different security policies and it also hides their private IP addresses. Both of these features add a small amount of security to the network. Maybe not much, but hopefully enough to prevent some attacks or delay them until IDS and counter-measures can be used effectively.

Re:Translation

[AKAImBatman]

As I wrote in my previous comment, these networks contain several servers. Most of these servers are public and are intended to be accessible by almost anybody, so darknets are not really appropriate in this case.

I think you misunderstand my point. I'm not saying that your entire network would be dark, just the part that's not public. i.e. If you have 500 desktop machines that are routable to the internet, the firewall will make those machines "dark" by denying incoming requests to that portion of the network. However, server traffic would still be allowed according to the firewall rules.

The kind of scenario that I am trying to prevent or make more difficult by using NAT is the following: some of these servers have "interesting" contents on them and could be juicy targets for some attackers (no, I'm not talking about pr0n here but about some company internal information). These servers are usually well protected and have only one or just a couple of services exposed to the outside world (e.g., HTTP). But other servers may not be so well protected because they run experimental code for public testing or demonstrations, or simply because they run a larger number of services that may be vulnerable to zero-day exploits. If one of these "weaker" servers is compromised, I do not want it to be used as an intermediate step to launch an attack on other servers on the same network (behind the firewall).

I don't see how NAT helps this? If you've got the weaker services exposed, you've got them exposed. Period, end of story. However, if your firewall rules deny routing except to the secure services, you're as safe as you are with NAT.

Just because you have a DMZ doesn't mean that you have to turn off your firewall security. (Unless you have a really sucky firewall, that is.) You can still control the traffic going in and out of your network. For example, I might place server A into the DMZ. By default, all the ports of the machine are now open. However, that's a pretty dumb thing to do, so I immediately allow ONLY ports 80 and 443. The machine is now secure against external attacks from outside the network.

Now let's say that I add development server B to the same network and DMZ. (Why I would do that, I have no idea. But that's your scenario, not mine.) Since it's just for internal development, I will only allow incoming connections from the darknet portion of the network to machine. All external routing is disabled for that machine. Whammo, one properly firewalled network.

Re:Translation

[vertinox]

There are also some features of NAT that I would like to keep even when using IPv6, the main one being the ability to hide the topology of my networks from the outside world.

Security from obscurity won't help you from an attack form the inside. If someone got a Trojan on a desktop behind the NAT or was the person simply sitting at a machine on your LAN, then NAT as a security method has been simply bypassed.

The same thing applies to an IPv6 network since by its nature IPv6 also cannot defeat an inside attack, but otherwise you can have your firewall refuse to let any communications to those boxes to the outside world and hide your topology that way.

Just because your boxes have addresses that could theoretically called up by someone from the outside won't make a difference if all traffic is denied by default unless it comes from certain addresses.

I want to also mention it maybe a bit more difficult for a man on the inside to port scan the LAN if you are using IPv6 due to the range of possible addresses.

Re:Translation

[Zarhan]

Indeed - the presentation I linked talked about how to find hosts otherwise than scanning (DNS, Sequential order, guessing MAC addresses for EUI-64 notation, etc). Never said that it would provide security, just that you cannot necessarily brutefocescan it :)

Re:Translation

[Raphael]

[...]These servers are usually well protected and have only one or just a couple of services exposed to the outside world (e.g., HTTP). But other servers may not be so well protected because they run experimental code for public testing or demonstrations, or simply because they run a larger number of services that may be vulnerable to zero-day exploits. If one of these "weaker" servers is compromised, I do not want it to be used as an intermediate step to launch an attack on other servers on the same network (behind the firewall).

I don't see how NAT helps this? If you've got the weaker services exposed, you've got them exposed. Period, end of story. However, if your firewall rules deny routing except to the secure services, you're as safe as you are with NAT.

What I tried to explain is that my firewall has to allow access to some servers that must be public and at the same time run code that may not be as secure as I would like it to be. Some of these services must be available for testing by partners or for public demonstrations. Public testbeds just have to be public, so I cannot restrict the range of source IP addresses.

Just because you have a DMZ doesn't mean that you have to turn off your firewall security. (Unless you have a really sucky firewall, that is.) You can still control the traffic going in and out of your network. For example, I might place server A into the DMZ. By default, all the ports of the machine are now open. However, that's a pretty dumb thing to do, so I immediately allow ONLY ports 80 and 443. The machine is now secure against external attacks from outside the network.

Limiting traffic to a web server to ports 80 and 443 is of course the first thing to do. But what if this web server runs some vulnerable CGI script, PHP script or Java servlet? What if this vulnerability allows an attacker to get shell access on that box? Suddenly, your whole DMZ is open to internal attacks that are remotely controlled from the outside. Your tight firewall setup becomes much less useful in that case.

This is exactly what I am trying to prevent by having multiple disjoint networks hidden behind the NAT+firewall box: the secure servers with important information go into one network, the servers containing experimental code that must have public access go into another network, etc. And I do not give too much information to the attacker about which server (or service) is in which network. So if someone ever manages to find a vulnerability in one of these servers, I do not want to make it too easy for them to find the private addresses of the other servers. This is just in case one of the other servers would be vulnerable to an attack from the local network. Of course this should not happen, but... better safe than sorry.

From my point of view, any additional effort that is required from the attackers is a good thing. If I force them to perform a noisy network scan to locate the other hosts on the internal network or to play ARP tricks, then they will be detected and isolated quickly. In the unlikely case that they would manage to attack other internal hosts anyway, then at least the damage would be limited to that specific network. Again, this is just a little addition to multiple layers of security. Every bit helps, so I like this NAT setup.

Re:Translation

[jez9999]

However, this "getting rid of connectivity issues due to no longer having to NAT" has NEVER been expected by anyone who knows even a bit about networking. Because we're not returning to an un-firewalled world.

I have to disagree. In my experience, it's not firewalls that cause a major problem with connectivity, because any half-decent firewall can be configured to let what you want through. It's the ever-increasing number of machines out there behind NATted connections (think home wireless routers, for one). I can't just write an app to connect between 2 machines using IP addresses anymore. It's not that simple. If they're both NATted, you're basically fucked and end up having to use something like Hamachi. I, for one, will cheer the day NAT dies. Using NAT as a firewall is like using an anchor for your car's brake. Does the job but in a crappy, unintended, unconfigurable way.

Re:Translation

[strikethree]

I am not sure why you are fixated on NAT. I am hearing you say that you want to control how packets traverse (or not traverse) portions of your network that you consider sensitive. What you are describing is a firewall. A firewall controls packets based on rulesets that you design. Those rulesets can be based on any aspect of any particular packet that you wish: destination address, source address, TCP, UDP, payload, etc. The possibilities are limitless unless you get some sort of braindead commercial firewall.

NAT is an archaic concept and must be tossed aside.

strike

Re:Translation

[Tony Hoyle]

Just run an ipv6 nat.

It won't be an issue though - ipv4 isn't going anywhere, despite what some would have you believe.

Re:Translation

[Tony Hoyle]

want to also mention it maybe a bit more difficult for a man on the inside to port scan the LAN if you are using IPv6 due to the range of possible addresses.

Not at all. Just get one of them to respond to something - send out a nebios request, an LLMNR request, anything - any you have an instant list of usable IP addresses.

NAT stops these getting *outside* the firewall thus increasing the security. Not by much, but it is definately there - I've been in many companies where they have public IPs for their network and *still* NAT at the firewall to stop information leak. ipv6 won't change this.

Re:Translation

[dodobh]

You can just use a proxy. Use a REAL firewall, not just NAT.

Re:Translation

[linuxrocks123]

> Because we're not returning to an un-firewalled world.

Returning? I'm already in one. Why would I want to firewall my machine? If I'm running a service, then it automatically has an open port and I need access to it from the outside, so I'd have to punch a hole through the firewall. If it doesn't have an open port, then the port is closed and therefore secure.

Firewalling it would be stupid; it would be just one more thing that can fail to work. No way in hell am I firewalling anything.

Re:Translation

[Zarhan]

So you've implemented a DMZ. Nothing special about that.

And besides, you just might want to block all the *other* ports anyway, even in DMZ deployment. And maybe put some sort of IDS system to check on the traffic going to that open port.

Yippee! I love NAT

[sckeener]

Yippee! I love NAT!

I still want IPv6, but I really do love my NAT. It is like loving microsoft...I like products that generate their own tech support.

Why firewall at all?

[Anonymous Coward]

Firewalls - specifically, network based firewalls - seem like an outdated concept to me. Why not simply lock down the endpoints (host based firewalls or service limitations are perfectly legitimate, but IPSec or similar seems better)? If we do that, we isolate troubleshooting to just the endpoints involved (did the packet leave, arrive, etc) and have complete flexibility and granualarity in securing our systems. We can easily enable access on one port, to one system, without compromising everything else. And, isn't security about saying yes as opposed to saying no? Maybe IPV6 will be what finally motivates us as an industry to get rid of antiquated technologies like network firewalls.

Re:Why firewall at all?

[mbone]

I find that the obsession with Firewalls is a Windows phenomenon. If you have a pure Linux or Unix shop, you can get buy with some ACLs on your routers. People with Windows shops seem to be migrating to a Port 80/443 only world, which is sad, really.

Re:Why firewall at all?

[slash-tard]

To nitpick a router that blocks traffic is acting as a firewall.

Firewalls also almost always act as routers.

A router using ACLs also needs to be aware or session state in most cases.

"Firewall" products tend to offer more advanced features such as central policies, logging, advanced log filtering, alerting, etc.. Its not just windows users that want these features.

In order to help technology progress

[Timesprout]

I hereby announce I am giving up my obsession with firewalls and reverting to my earlier obsession with Halle Berry.

Re:In order to help technology progress

[jddj]

Sorry - after IPv6 is fully rolled out, Halle Berry is deprecated in favor of Kirsten Dunst...

Re:In order to help technology progress

[Pollardito]

good luck with your new crush. if you're looking to sell all your old pin-up posters of firewalls i'm sure that there is a market for that sort of thing on this very site

Re:In order to help technology progress

[archen]

Then thank god that day will never come =)

Re:In order to help technology progress

[Anonymous Coward]

You could help make leaps and bounds in neuroscience. http://www.physorg.com/news4703.html

Firewall != NAT

[0racle]

You can have a firewall that does not use NAT. Both sides are publicly addressable but there is still a security device between you and the outside world.

Re:Firewall != NAT

[maestro371]

I agree. This article is FUD. The problem the article claims is in the fact that it is desirable to restrict traffic to only that which is initiated from the inside. Of course protocols like FTP and BitTorrent will always have a problem with this whether it's IPv6 or IPv4. Such protocols are in direct conflict with the "internal initiation" paradigm. I don't see the value of this article beyond, "Firewalls are suxx0rs!!".

Re:Firewall != NAT

[dubbreak]

You can have a firewall that does not use NAT.

Quite true, however most consumers would think of their home router as a firewall (the majority of which do NAT). You have to write to your audience (and although I did not read the article in true slashdot style) I would assume it is aimed at more than just geeks if they are simplifying NAT as a "firewall".

Re:Firewall != NAT

[DragonWriter]

But most consumer routers have to do NAT for reasons other than security, but because of the limited externally-exposed IP address range most consumers have.

Wasn't one of the whole points of IPv6 to expand the address space to alleviate this problem? Doesn't it do it quite effectively? My understanding was that the answer to both is yes, which suggests that consumer routers in an IPv6 world ought to be able to act as firewalls for security, without doing NAT.

It has already happened

[The One KEA]

Linux has already gone down this path - the old IP connection tracking code in the Linux iptables packet filter has already been reworked into a more general layer-3 connection tracking mechanism, with separate 'drivers' for tracking the IPv4 and IPv6 protocols and separate 'plugins' that can handle specialized protocols (FTP, IRC, H.323, PPTP and so on).

I suspect that commercial firewalls will probably follow suit.

Its ridiculous even having to rely on firewalls

[SkunkPussy]

Is it a good idea to expect that whenever and wherever a mobile computing device connects to a network, there will be a properly configured firewall ready to protect it, or should computers and other networked devices be able to function securely without an external firewall to protect them?

Its a nonsensical situation that operating systems in general cannot be relied upon for the security of their own network interfaces - after all it is down to the operating system to accept or reject user logins. In the same way it should be the operating system that sets policy about whether to accept or reject packets from arbitrary locations.

A firewall is roughly equivalent to a plaster on an open wound - it serves a useful purpose, but nobody should expect to walk around with an open wound on a long term basis.

There is little if anything that a firewall can do that an operating system can't.

Re:Its ridiculous even having to rely on firewalls

[RockRampantly]

Its a nonsensical situation that operating systems in general cannot be relied upon for the security of their own network interfaces - after all it is down to the operating system to accept or reject user logins. In the same way it should be the operating system that sets policy about whether to accept or reject packets from arbitrary locations. A firewall is roughly equivalent to a plaster on an open wound - it serves a useful purpose, but nobody should expect to walk around with an open wound on a long term basis. While I agree with you that a firewall protecting a single IP is rather useless - the OS should take care of itself - a firewall is definitely useful when protecting a group of machines. It can be used to create a relatively trusted network without having to worry about interference caused by rogue packets from the outside.

Re:Its ridiculous even having to rely on firewalls

[Anonymous Coward]

Clearly you don't use Windows...

Re:Its ridiculous even having to rely on firewalls

[sjwest]

While they might be crude they do the job, we get a number of ssh hackers and whatever doing there best to enter our systems over wired connections and crude it might be i would not want to be running a microsoft os - like many /.'ers we have several routers just to protect windoze and the ancient print servers which i'd rather not give a public ip to.

Re:Its ridiculous even having to rely on firewalls

[Vellmont]

Its a nonsensical situation that operating systems in general cannot be relied upon for the security of their own network interfaces - after all it is down to the operating system to accept or reject user logins. In the same way it should be the operating system that sets policy about whether to accept or reject packets from arbitrary locations.

In general the software firewalls that come with Operating Systems are quite reliable and can be trusted.

What can't be trusted is that all the firewalls on every machine are configured properly. It's FAR easier to administrate one firewall than it is to administrate 10 or 100 different workstations/servers.

Re:Its ridiculous even having to rely on firewalls

[Anonymous Coward]

What they mean is a router with firewall capabilities, or clients behind a router which each run a firewall. NAT (except binat / 1:1 NAT) normally didn't do portforwarding. Now all ports are wide open. Another solution is simply having external and internal IP(v6)s and by default only binding on internal IP(v6)s. That'll keep the morons from running all kind of stuff out of the box. Or let them learn the hard way. Why bother?

Re:Its ridiculous even having to rely on firewalls

[Lord Ender]

Let me translate what you said.

"In an ideal world, we would not need so many layers of security! The world should be ideal, damn-it!"

My response to you is that we don't live in an ideal world, and in the REAL world, defense in depth has proven to be an incredibly useful security model.

You can keep ranting against reality if you like, but you won't change anything.

Re:Its ridiculous even having to rely on firewalls

[Syberghost]

There is little if anything that a firewall can do that an operating system can't.

Assuming you weren't stripping NAT out of the equation (and if you were, you were horribly offtopic or disingenuous or both), an operating system can't keep your ISP from being able to invade your privacy and charge you per-device unless it's been configured to act as a NAT firewall. (Silly semanatic arguments as to NAPT/NAT aside.)

Re:Its ridiculous even having to rely on firewalls

[Anonymous Coward]

I think you can make an equally valid claim that it's nonsensical that the network cannot be relied upon for security. Common functionality should reside in shared resources. Isn't that what modularity is all about?

Re:Its ridiculous even having to rely on firewalls

[rHBa]

I think the parent meant that you shouldn't (in theory) need ANY firewall, hardware OR software.

If you can trust that all the services running on your box are secure (i.e you're not listening on any ports with insecure services) then you don't have an open wound and don't need a plaster.

Re:Its ridiculous even having to rely on firewalls

[glwtta]

There is little if anything that a firewall can do that an operating system can't.

Except maybe be one box, instead of 200?

Re:Its ridiculous even having to rely on firewalls

[Vellmont]

I think the parent meant that you shouldn't (in theory) need ANY firewall, hardware OR software.

Maybe, but the author referenced the OS, not services that run on an OS.

Anyway, if we start talking about the way the world SHOULD be, there's a lot of things that'll come before all services being secure.

I'd be more interested in what's possible than what should be. I think there's a lot of improvements that can be made on multiple levels of the software stack. But that doesn't mean there's not always going to be the need for multiple levels of security that cover for each other. You really should never be trusting any single component to be perfect.

Re:Its ridiculous even having to rely on firewalls

[renoX]

>>There is little if anything that a firewall can do that an operating system can't.
>Except maybe be one box, instead of 200?

Except of course, that it only works in very specific situations, in general 'defence in depth' is much less brittle..

Re:Its ridiculous even having to rely on firewalls

[Just Some Guy]

There is little if anything that a firewall can do that an operating system can't.

Ahh, but here's the deal: I can tell my firewall that "incoming port 25 connections are only allowed to such-and-such machine". After that, no matter how badly a random host on the LAN gets compromised, it can't become a zombie spam relay. Default-allow firewalls are mostly useless. Default-deny, though, makes for a nice protection layer.

I like my firewall, thanks

[Carrion Creeper]

I would say I personally am not obsessed with firewalls per se, I'm obsessed with privacy and security.

The firmware on a firewall also has a much smaller amount of code to debug in order to make sure that it will function properly all the time. I would never assume that my Windows XP machine was properly patched with enough confidence to plug it straight into a cable modem all the time.

I am also not interested in having each computer in my home being identified and tracked individually, and I don't pirate software or download music. As such, even if the need for NAT is removed, I would still be highly interested in purchasing a device to block incoming connections and mask my IP address (maybe by swapping with other devices within my home on certain connections).

Privacy Concerns?

[WiseWeasel]

It seems strange that people are arguing about getting rid of NAT devices and having unique IPs for every device without bringing up the privacy implications. It seems that having unique addresses for every device is a small step away from being able to track and monitor every device on the net. Without the ability to proxy or perform NAT services, every device would be exposed to the net, and would leave a reliable trail of activity. It seems that this would encourage governments to think that they can control and enforce the web, and deal a pretty strong blow to the level of anonymity granted by the current network topology. I just hope that if this does come to pass, that there will be solutions to mitigate this risk, to help obfuscate individual activity on the net. This hazard to troubleshooting network issues, as described in the summary, might be an important factor in ensuring privacy and a certain degree of anonymity on the web.

Re:Privacy Concerns?

[blosphere]

Put a firewall up and don't allow devices that you don't want to be seen in the internet. Problem solved.

Or make your main machine a proxy and every other device in your network talks thru it.

Re:Privacy Concerns?

[Imagix]

You need to do some reading on IPv6 and Temporary Address allocations. Also, a device may have multiple IPv6 addresses (as in, multiple routable IPv6 addresses).

Re: Privacy Concerns?

[FreezerJam]

Not to mention your average consumer ISP, which, like a cable company, would love to start charging "per outlet".

Much as a NAT-less world might be easier to build and debug, I think I'm happier if my network connection is like my electric connection.

One connection delivers: all electric energy / all bits
I can go up to a max of: 200 amps / 5 Mbps
I might still be billed: by energy used / by gigabytes sent
But I don't pay extra: for more outlets / for more devices
I cover all the costs: of the electric panel / of the router

Handing someone else the information to break the above model is not something I want to do.

Re: Privacy Concerns?

[Anonymous Coward]

But I don't pay extra: for more outlets
Only if you ignore needing permits/electrical safety inspectors/contractor to put it in etc...

Re:Privacy Concerns?

[Lord Ender]

People who want anonymity can buy anonymizing services. If there is enough demand, it might be offered by consumer ISPs directly.

Re:Privacy Concerns?

[fishbowl]

>People who want anonymity can buy anonymizing services.

If there is a mechanism for the purchase, there is a weak point in the anonymity.

>If there is enough demand, it might be offered by consumer ISPs directly.

Which consumer ISP will be the first one to allow one of its execs to go to jail in order to protect the privacy of one of its users?

Re: Privacy Concerns?

[Canthros]

You need a contractor to put in a new outlet? Hell, unless we're talking about cutting open the wall to run wiring, there's nothing to it. (And, if we are opening up the wall, it's just tedious and time-consuming. If the wall's already open, you throw the breaker on the circuit you're adding the outlet to, add a junction box, splice in the new run of wire, run the wire to the box for the outlet, wire up the outlet, tie up the splices in the junction box, seal up the boxes, et voila: new outlet. As long as you're not overloading the breaker, using too small a guage of wire, or really sloppy in your splices, there really shouldn't be anything to worry about. On the other hand, I'm not an electrician: too bad, really. They make good money.)

Anyway, he's obviously referring to the fact that you don't pay your local P&L per outlet in your home, much as you don't pay your broadband provider per computer on your internal network (although, I'm pretty sure your broadband provider's contract is written such that you're supposed to. Whatever.). Plenty of people don't run their own network cable or set up the network themselves. Those sorts of folks keep people I know in business.

Re:Privacy Concerns?

[Lord Ender]

If you think that's the way this works today, you are fooling yourself. NAT and dynamic IP addresses do NOT give you anonymity. They just make it tricky to identify you without a court order.

Re: Privacy Concerns?

[Anonymous Coward]

Well that's a one time cost, and you can effectively add more outlets by buying powerstrips which don't require inspectors.

Re:Privacy Concerns?

[evilviper]

It seems that having unique addresses for every device is a small step away from being able to track and monitor every device on the net.

It's not as if large ISPs are doing NAT for all their customers.

Your NAT box's IP address is more than enough for anyone to uniquely identify households...

With IPv6, you have thousands of addresses to play with... Want to change the address of your computer every hour??? Go right ahead.

Of course, these addresses are all under the same subset, which can be aggregated and perhaps narrowed down to the household level...

So you're really no worse off.

Not to mention, your public IP address isn't the information you really need to be worrying about. Things like cookies, user agents, stack fingerprinting, etc., etc. allow pin-pointing specific devices, and specific users of each device.

Re:Privacy Concerns?

[Tony Hoyle]

Put a firewall up and don't allow devices that you don't want to be seen in the internet. Problem solved.

  and the outgoing connections.. oh you've got to hide those - perhaps by changing the address... like.. um... NAT?

Or make your main machine a proxy and every other device in your network talks thru it.

You misspelled 'router'.

Re:Privacy Concerns?

[Tony Hoyle]

Temporary addresses is just NAT in new clothing. Instead of one IP you're randomly generating different ones every few hours. It has exactly the same problems and offers no new solutions.

Re:Privacy Concerns?

[Anonymous Coward]

You misspelled 'router' No, you don't understand proxy, it's different than a router.

Re:Privacy Concerns?

[Imagix]

Not true. The temporary addresses are routable, and nearly indistinguishable from "normal" routable addresses. NAT addresses on the other hand may require intermediate devices to perform some sort of address translation (hence the name NAT...) both at the IP protocol layer as well as potentially within the application data layer (such as FTP and SIP). If the end users happen to be encrypting their SIP traffic for example, the NAT gateway has no way to adjust the SIP data to use the correct IP. With IPv6 temporary addresses, the SIP traffic will contain a properly routable address which will not need to be translated.

128 bits

[CrtxReavr]

Since we have the attention of the IPv6 crowd, everyone should add this record to your forward zones:

aacs IN AAAA 09f9:1102:9d74:e35b:d841:56c5:6356:88c0

-CR

same old

[spykemail]

The more things change the more they stay the same. The human race is suffering from new forms of the same problems it has had for thousands of years, you can't expect communication protocols to do too much better.

IP6 is too complicated

[Viol8]

Its easy to manually configure a network using IP4. Try doing it using IP6 with its incomprehensible 128 bit hexcode addresses. But its self configuring the IP6 proponents exclaim. Oh yeah , and thats really fullproof isn't it. Not. There always end up being manual intervention with any network topology and trying to do it with IP6 is like trying to pull teeth with a very sharp paperclip - painful and slow.

Re:IP6 is too complicated

[Just Some Guy]

I know you must be trolling, since configuring IPv6 is mostly identical to setting up IPv4. Type an address, a prefix length, and a gateway and go. What's so tricky about that?

Re:IP6 is too complicated

[T-Ranger]

Pfft. Thats like complaining that no one should buy 2x4s because you like making them yourself with glue and toothpicks. The goal of a network is to get stuff done, not to demonstrate the size of your cock to your networking geek friends.

Re:IP6 is too complicated

[Ant P.]

Whoa whoa, don't push the guy! He's still struggling with English, let alone computers.

Re:IP6 is too complicated

[Viol8]

"Type an address, a prefix length, and a gateway and go. What's so tricky about that?"

You ever tried to type in a three dozen IP6 address manually and then have to go back and find the typo? No , didn't think so. Idiot.

Re:IP6 is too complicated

[Viol8]

Whoa whoa, that was such a killer putdown (not) , trying to karma surf on the back of his comments. Aww , didn't work though did it?

Re:IP6 is too complicated

[Just Some Guy]

You ever tried to type in a three dozen IP6 address manually and then have to go back and find the typo? No , didn't think so. Idiot.

You're manually configuring a network of about 40 computers and I'm the idiot. Irony, thy name is Viol8.

Re:IP6 is too complicated

[Viol8]

"You're manually configuring a network of about 40 computers and I'm the idiot. Irony, thy name is Viol8."

Oh right , so you've never had issues like we've had with IP6 autoconfig but yet you know it all and I'm the troll?

You really are a twat arn't you. Still, that somes up a lot of people on here - A grade know-nothings.

Editor

[Anonymous Coward]

"and looking a the re-emergence of old problems in new guises"

Looking eh? I don't understand what all the fuss is aboot!

IPv6 is comming, very soon now...

[coryking]

Moan and groan about firewalls and "what is the point?" but I'll tell you what... Vista now ships with IPv6 enabled by default! All that is left is getting my DSL connection, upstream, and the rest of the internet to speak it and I'll be golden.

But seriously, I used to think IPv6 would never catch on, but in a few years maybe 65-85% of the world will be running an operating system that has it on by default. Hard to argue with that!

Re:IPv6 is comming, very soon now...

[jimicus]

in a few years maybe 65-85% of the world will be running an operating system that has it on by default. Hard to argue with that!

The World is Not A Bunch of Windows PCs.

The remaining 15-35% of the world will be running systems which don't lend themselves to upgrading. Old routers which are no longer supported by the manufacturer (just because a telco may regularly upgrade its core network doesn't mean it also regularly upgrades everything else), older proprietary OSes without IPv6 support (or which have IPv6 support provided you're prepared to pay $$$$).....

Re:IPv6 is comming, very soon now...

[badfish99]

But all those 65-85% will be completely unable to communicate with each other using IPv6, as most ISPs have not adopted it.

And if your ISP does support IPv6, then just for fun try turning off IPv4 and see how far you get. The number of web sites using IPv6 seems to be approximately zero.

Re:IPv6 is comming, very soon now...

[808140]

IPv4 sites can be accessed with IPv6; IPv6 addresses include IPv4 addresses as a subset. On IPv6, you can access the entire IPv4-only internet; it is the IPv6-only internet that you cannot access with IPv4. That currently constitutes a minuscule number of sites, so it is no great loss, but once IPv6 begins to take hold -- and it will, China, India and Japan do not have enough addresses given their populations -- people who insist on using IPv4 will begin to find that large swaths of the internet are inaccessible.

It's not like anyone is expecting an overnight change, as IPv6 was designed to co-exist with IPv4 for some years. But once the number of IPv6 sites reaches some critical mass, abandonment of IPv4 will be quick. Early adopters of IPv6 will absolutely not find themselves penalized, assuming that their ISP does in fact support IPv6, as they can do everything they can currently do with IPv4 with IPv6 and possibly more.

Re:IPv6 is comming, very soon now...

[badfish99]

IPv4 sites can be accessed with IPv6
Well no, they can't; that's the problem. Certainly all IPv6 implementations also implement IPv4. But there's no way to access (say) google via IPv6, as it hasn't got an IPv6 address. So there's no motivation for ISPs to invest in IPv6 infrastructure, as their customers can't use it. And there's no pressure from their customers to support it, because no-one wants to be the first big web site to cut themselves off from the mass of IPv4 users.

Perhaps the Chinese will adopt it, though; they actually want to cut themselves off from the rest of the internet.

Re:IPv6 is comming, very soon now...

[Tony Hoyle]

IPv4 sites can be accessed with IPv6; IPv6 addresses include IPv4 addresses as a subset.

I hear this every time this discussion is rehashed on slashdot but it's total bull.

So what if you can ping from 2001:8b0:178:1:4c0:7a76:5b44:af81 to 2002:4223:fa96::

Firstly the slashdot server wouldn't even receive the packet unless it has an ipv6 capable stack at that end.
Secondly - *even if it could* then it couldn't reply, because 2001:8b0:178:1:4c0:7a76:5b44:af81 is not an ipv4 address nor does it map one.

stateless firewalls

[greenrom]

You can have a firewall without using NAT. Being able to assign every device a routable address means that you can implement a stateless firewall instead of a stateful firewall. For most purposes, a simple firewall that filtered incomming TCP connection requests and UDP packets on all ports except those specifically allowed would suffice. This has the advantage that the firewall wouldn't need to track the state of TCP connections, and would eliminate problems like firewalls deciding a connection has been idle too long and closing it.

For the home user, being able to assign a routable IP to every PC has other advantages. Do you have multiple PCs with Remote Desktop running that you want to access remotely? NAT makes this difficult since all the PCs share the same IP address and need to listen for connection requests on the same port. Assigning every machine a routable address makes this problem go away. Don't like that example? The same applies to a web server, or SIP phone, or Bittorrent, or a myriad of other applications.

Re:stateless firewalls

[gclef]

Just for fun, try running SIP or H323 through a stateless firewall sometime. Since you're advocating stateless firewalls, I can tell you've never tried....it doesn't work.

SIP, H323, and a bunch of other protocols that are starting to be used regularly as business needs, dynamically allocate ports. You won't know what ports you'll need to allow through the firewall, since they'll be different for every connection. The only way this works is if your stateful firewall understands enough of the protocol to learn which ports it's expecting to see a response on. (In the case of H323, the response may even come from a totally different IP.)

This is precisely the problem that will continue to be the case in IPv6.

Re:stateless firewalls

[greenrom]

The SIP part of it can use a single port. RTP ports are dynamically allocated, but most phones will use a fixed port range or let you specify one. So basically, that means opening up port 5060 for SIP and lets say something like 8000 - 9000 for RTP. The alternative would be to have a stateful firewall as you suggest that parses the SDP out of the SIP invite to figure out which UDP ports to open for the RTP streams and then watch for the BYE packet to close them. I don't know of any home routers that can do this, though I'm sure there are commercial solutions. The advantage to using IPv6 is that a home user could open up the same ports for each PC and have a SIP phone running on each one (or multiple hardware SIP phones throughout the house). With a single NATed IPv4 address, most home users would be limited to running a single SIP phone. The only workaround for IPv4 I can think of would be for the user to run their own registrar behind the router.

Re:stateless firewalls

[kalugen]

This is totally correct, but there are also other problems with stateless firewalls...

Let me explain what a stateful firewall does (not to you obviously, but I'm reading comments from lots of people that do not seem to fully understand the issue).

A stateful firewall can filter traffic not by just "blocking" some protocols or addresses/ports.

It can police traffic using the abstraction of "connections": you are able to tell it "allow NEW connections to this service, but not to that. And please let come in all traffic that pertains to already ESTABLISHED connections. Discard all INVALID - not NEW or ESTABLISHED - traffic" (yes, I'm taking the terms directly from linux's iptables/netfilter).

This is not simple as it seems... first, there are lots of problems with defining what a "connection" is just by looking at the traffic from the kernel's POV because is usually an application's (user space) work to make sense of all those bytes carried in the payload of TCP/UDP packets.

For plain old tcp session, like the ones used by SMTP or HTTP, this is easy: the protocol itself has the concept of "sessions" (every packet carries a "sequence number" that is used to identify the packet as part of a "session" - yes, this is a possible attack vector, and no, it's not _that_ easy to guess/brute force them. Not anymore). So, HTTP/SMTP and the like are EASILY firewalled and NATted.

But with ICMP or UDP? You have to do some smart tricks in order to implement the "connection" concept, for example: ok, we do not have session numbers, but if you send an ICMP echo request to an IP address, we should expect an ICMP echo reply to come back sooner or later from that same IP address, so here is your ICMP "session" (almost). Sending an ECHO request and receiving (or not) an ECHO reply is what actually happens when you use the "ping" command.

And beasts like FTP or SIP, H323, PPTP... the lot? Those nasty guys generally work by opening a TCP "control" connection, where protocol commands and responses are expected to travel... at some point during the conversation someone issues a command telling the other part(s) to expect a new connection on some other port and maybe with some other protocol... this command means something only to the high-level applications implementing these high-level protocols. It doesn't mean shit to the kernel, because this is not IP, TCP, UDP or ICMP: it's an higher level abstraction.

This is why you have to write special "helpers" for these protocols to bridge the gap and make things work: the "helpers" can intercept and understand the high level protocol commands and manipulate the kernel's notion of what low level traffic is RELATED to an already ESTABLISHED connection, because the kernel can't tell by itself.

In the case of FTP, the corresponding helper looks for the command "open new connection on port xxxrandomxxx for data transfer" (actually, the PORT and PASV commands) in the traffic travelling through the firewall, it figures that the important part is "port xxxrandomxxx" and then marks as "RELATED" traffic coming/going to port xxxrandomxxx (yes, "helpers" are another attack vector, and no... they are generally smarter than in my description, I am oversimplifying... (*)).

The same tricks are needed for some forms of NAT: specifically, the one when you have many hosts/PC on the "inside" and just one public routable address on the "outside" - Cisco calls this "PAT" - so the firewall needs to track "connections" to succesfully map traffic between external and internal hosts. Other forms of NAT includes the much simpler 1:1 (you have 'n' internal addresses and 'n' external addresses) and do not _require_ the tricks.

Having said all that...

Accepting ESTABLISHED tcp connections from port 80 (http) is a LOT different than just allowing generic tcp packets whose source is port 80 to come in, for example.

In the first case you're allowing only legal traffic that constitutes a response to your requests, as per th

Re:stateless firewalls

[evilviper]

Being able to assign every device a routable address means that you can implement a stateless firewall instead of a stateful firewall. For most purposes, a simple firewall that filtered incomming TCP connection requests and UDP packets on all ports except those specifically allowed would suffice.

Congratulations! You can't access the internet!

"Stateful" firewalls are precisely what allows you to allow in-bound replies to out-bound requests, without leaving every port (above 1023) fully open. Try to do this, and you won't get anywhere.

This has the advantage that the firewall wouldn't need to track the state of TCP connections, and would eliminate problems like firewalls deciding a connection has been idle too long and closing it.

Firewalls keeping state information is decidedly not a burden. If the software is written to do it, and the hardware isn't some 5MHz 8080, there's really no penalty. Connection time-outs are a rare enough occurance, or else the default time-out periods would be increased, and networked software can deal with dropped connections easily enough...

Re:stateless firewalls

[dodobh]

The ability to tell the firewall "allow ESTABLISHED traffic" is also orders of magnitude simpler than having to specify every single allowed protocol/protocol flag/port/address in the rules (where it is possible at all).

This is why we have stateful firewalls.

The ability to ignore the layer 3 crap and actually secure applications on the network by using a proxy is far more useful than a "stateful" packet filter.

Yes, you need a proxy per protocol, but those need to be written ONCE.

My brain hurts...

[evilviper]

This seems to be the kindergarten introduction to firewalls, written by someone who is feeling around in the dark, and doesn't really know what he's talking about...

So what's the point of the pages full of irrelevant details about how Vista and ZoneAlarm works?

Stateful firewalls require you to explicitly allow incoming connections certain ports, even with IPv6. That's it. Nothing else there.

What he completely misses is that this is worlds better than NAT, which also requires assigning a unique port on the single IP address... You're screwed if you want more than one machine to access the same service, which doesn't allow you to use a non-default port.

Want two web servers running (on port 80)? Want two machines to be able to receive VoIP calls? Want multiple machines to be able to play some online game? Too bad. It's only with the multiple addresses IPv6 offers that it's really possible.

Re:My brain hurts...

[Isvara]

NAT != 'single IP address'. I have more than one host accessable from the Internet via port 22, on different IP addresses, and they're both behind the same NAT gateway. To put it another way, masquerading, which is what you're talking about there, is a superset of NAT.

Re:My brain hurts...

[evilviper]

masquerading, which is what you're talking about there, is a superset of NAT.

Now that's just being pedantic.

Firewall but without a NAT?

[garlicbready]

maybe I'm missing something here as I admit I'm not fully aware of the low level details of network implementation
but wouldn't it be possible to still have a Firewall but without a NAT?

i.e. instead of devices pretending to be just the one IP address that's been assigned to the router via NAT, they instead each have they're own addresses
However all communication still physically goes through the router / firewall / same device to filter out any incoming dodgy packets via SPI, or put limits on incoming communications (port filtering for given IP ranges for internal devices) to make sure that access is only granted when requested instead of by default

Re:Firewall but without a NAT?

[KingMotley]

Yes, which renders this whole article complete garbage.

Re:Firewall but without a NAT?

[dbIII]

but wouldn't it be possible to still have a Firewall but without a NAT?

From all the comments here it appears that majority of the posters have learned more about computer networking 101 than the author of the article. We may have found the next Dvorak!

Either that or I'm just too old and learned about routing first and NAT later when it was new.

A Firewall is still the right route in some cases

[ipjohnson]

For a lot of settings (Corporate,home etc.) allowing random access into your network doesn't serve any purposes. If you need to provide services you can serve them through the firewall or you can make a DMZ outside the firewall but there is no need to allow random access to your network.

That being said I totally agree that OS's need to be more secure but thats just part of the equation to proper network security.

The headline is dead on

[spywhere]

The media -- and the consumer anti-virus manufacturers -- feed our "obsession with firewalls," and I see it every day in the home-user world.
Computers sitting behind a NAT router, which is pretty much all the firewall most machines need, come factory-loaded with Norton Internet Security or McAfee Security Center. This makes it nearly impossible for the average home user to share files and printers, and (especially with Norton) makes it very likely that they will answer some of the hundreds of pop-up questions wrong and break something they want:

"MSIMN.exe is trying to access the Internet!
What do you want to do:
1. Permanently block it?
2. Dial 911?
3. Buy even more Norton crapware?

I try to explain to my customers that they want a hardware firewall (the router) and don't really need a software firewall other than the one-way jobbie that ships inside Windoze.
OTOH, one customer this morning still has an XP SP1 machine plugged directly into her cable modem... guess what happened to her machine?

Oh, well, I get paid to fix these kind of problems, so I guess I don't mind. God forbid they ever get it right!

Re:The headline is dead on

[0123456]

"I try to explain to my customers that they want a hardware firewall (the router) and don't really need a software firewall other than the one-way jobbie that ships inside Windoze."

I disagree. I most definitely want to know when some random program decides it's going to connect to the Internet and send information from my machine to some random server.

The problem is that so much cruddy software these days decides it wants to connect to the Internet for no good reason, even when I manually disable 'auto updating' and the like, that having the firewall turned on is a pain in the ass. It's apparently impossible to stop Acrobat Reader or Media Player trying to access the Internet every time I run them, for example... the only reason I haven't totally disabled them in the firewall is that I occasionally do want them to check for updates or new codecs or whatever. Who knows what the hell they're doing?

Re:The headline is dead on

[EvilRyry]

How many normal people are going to able to distiguish between necessary traffic, and unnecessary traffic? Not many. Especially Norton's target audience. For the average Joe, software firewalls that ask for permission are just another button to press that you don't really understand.

If you can't trust your current software, maybe its time to find some new software.

Re:The headline is dead on

[Anonymous Coward]

You, sir, are completely wrong.

The whole point of a firewall is to limit the *users* and *programs* that can make network connections. They only reason that most firewalls filter on IP addresses and port numbers is that they don't have any direct information about users and programs, so they try to guess based on addresses and port numbers. This is highly inaccurate and unreliable -- consider the issues mentioned in TFA, for instance.

The proper way to firewall is to look at the users and programs, and generate accurate mappings to addresses and port numbers as necessary. This way, all the problems described in TFA go away: FTP.exe is allowed to send and receive connections on any port that it wants, because the firewall trusts it to do so. MYDOOM.EXE will be denied, no matter what port it uses or how it disguises its traffic, because it isn't trusted.

Yes, correctly configuring application firewalls requires some user knowledge, and user education is a problem, but the current model, the one that you suggest, is fundamentally broken in many ways.

Re:The headline is dead on

[Tony Hoyle]

It also doesn't work, because people don't understand.

'Internet explorer wants to connect to the internet'. Well yes, that's what its for. User clicks 'yes'.

*however* that's not what the popup is about. It's trying to say that an application (in this case java running cisco SDM, but it could easily by spyware) is trying to open a listening port.

Click 'yes' and Windows allows the IE application to open ports - because that's what you've told it. Firewall rendered useless ready for the machine to fill with crapware and ultimately become a zombie.

IPv6 Needed?

[igb]

SO it's been more than 11 years since RFC1883, and there's been no non-toy deployment. Had IPv6 just been IPv4 with longer addresses, it might have been deployed, but they decided to add a load of extra features to complicate proceedings (the worst offender being mandating IpSec, which for practical purposes no-one uses for anything other than a minority of VPN clients). Normally a technology that has no major deployment after a decade is assumed to be dead: X.400 springs to mind, in many ways.

``Running out of IP numbers'' is like ``running out of oil'': it'll happen, but crying wolf didn't help the cause. It's claimed IPv6 is Big In Japan but, like popular beat combos, that means ``dead elsewhere''. And I"m sit in a hotel room in Tokyo happily IPv6-free, and i've just come from a building owned by one of the largest IT companies in Japan which was entirely IPv4.

IPv6 has been ``next year'' for the last ten years. It's still no-where. What'sdriving it now that wasn't driving it five years ago?

ian

Re:IPv6 Needed?

[jshriverWVU]

Thanks for the reply, wish I had some mod points for you. I haven't followed ipv6 that much, except for the random blirp now and then. But I agree it's been around for a long time yet never really used, so maybe it should be rethought or completely redone.

Re:IPv6 Needed?

[Znork]

"What'sdriving it now that wasn't driving it five years ago?"

Virtualization. Where you once had one machine serving several applications, it's now become trivial to separate applications into differing vm's for security, simplicity and scalability. You'll still want to adress the unique vm's, and ipv6 is a great way to do it.

Fast forward ten years and you'll have applications the way you have VM's today. Instead of deploying an app on a specific platform, you'll be able to deploy a VM image like you fork a process today. If you thought you needed IP's today, wait 'til your processes not only require their own PID but also their own IP address.

Re:IPv6 Needed?

[numbski]

Actually, the inability for the small guy to get an IPv6 allocation from ARIN is more than a bit annoying. I was willing to pick up a block of IPv6 addresses to built out my data center on, and then use IPv4 tunnelling where required. I couldn't get an allocation unless I had enough customers to use a full (IPv6) /32, which of course I don't. We're just starting out, so they basically force the little guy to use IPv4, and then do a migration later. This is LAME. They don't even charge for IPv6 allocations, so far as I can tell there's a monetary sub-motive here to squeeze as much money out of IPv4 as they can, and if you're big enough, they'll let you have IPv6 for free. If you're too small, either buy an IPv4 block, or go buy an IPv6 block from one of the big guys that got it for free. :\

Re:IPv6 Needed?

[pairo]

For one, IPSEC isn't mandatory in IPv6. And, secondly, I doubt that if IPv6 would've been IPv4 with just 96 more bits for the IP addresses, it would've been implemented.

Re:IPv6 Needed?

[drmerope]

IPv6 has horrible implementation consequences for hardware accelerated routing (i.e., every major switching device that interconnects the internet today).

The decrease in packet-per-second switching performance is severe and has been a critical road block to IPv6 adoption. Basically the IETF didn't have a clue about the consequences of adopting 128b addresses. Which each passing year silicon technology roughly follows Moore's law and is gradually getting ahead of the game (b.c. traffic isn't growing exponentially).

So five years ago IPv6 was completely ridiculous. In a few years the technology will catch-up and real IPv6 deployments can begin.

Anyways, there is no real shortage of IP space. There are only some gross mis-allocations: e.g., not very large companies which now control multiple class a blocks.

It is amazing that this article now attempts to spin firewalls as an obsession. Firewalls are in fact a core aspect of security unless you are able to carefully audit every device, every service, etc. People with dreams of their freezers having public IPs don't seem to get this: doing so would mean security auditing your freezers embedded OS!?!. Its crazy.

Also some people seem to be thinking that protocols requiring stateful firewalls are broken. This is false. Protocols that require the firewall to inspect the application layer contents are broken. But TCP is a stateful protocol, consequently firewalls should implement stateful behavior.

Re:IPv6 Needed?

[dave562]

When I read your comment I thought about how domain name registrations were originally free. Because of that, people went out and registered huge swaths of domains. If ARIN just gives out IPv6 address space, what is to prevent every geeek and their mom from running out and grabbing some of it just because it is there to be had?

Re:IPv6 Needed?

[funkatron]

I couldn't get an allocation unless I had enough customers to use a full (IPv6) /32, which of course I don't. We're just starting out, so they basically force the little guy to use IPv4, and then do a migration later.

Make up higher customer numbers then. It shouldn't be that difficult

Re:IPv6 Needed?

[Anonymous Coward]

Well, IPv4 has a 13-field header plus options, and allows fragmentation along the whole route. Plus a header checksum.
IPv6 explicitly disallows fragmentation, has no checksum and no optional fields to check for.
Now how can that be slower than v4 ?

The explanation has to be found elsewhere. I just found this paper (from 2004) which has an interesting analysis of the cost of operating v4 and v6 networks, taking into account the price of address blocks, etc.
http://www.usipv6.com/6sense/2004/dec/02.htm

That may be a better explanation.

Re:IPv6 Needed?

[Fyre2012]

...force the little guy to use IPv4...

The process for getting v4 IP's directly from ARIN complicates that a bit...

The minimum allotment is a /20, which is 4096 IP's, and for a 'little guy' it'd be pretty hard to fill up.
ARIN also demands that before you can qualify, you must use 75% of the allocation within 90 days of it being assigned to you, otherwise you run the risk of having the IP's revoked.

If you're Multi-Homed (multiple carriers terminating at the same endpoint [your network] using BGP) than the minimal is a /22, which is 1024 IP's, but it's the same deal with regards to allocating 75% of them within 90 days.

Re: IPv6 Needed?

[Dolda2000]

IPv6 has been ``next year'' for the last ten years. It's still no-where. What'sdriving it now that wasn't driving it five years ago?

What's driving it is what has always been driving it: a NAT-free internet. Many protocols would be more than happy with that, not least the various P2P protocols, where clients actually connect to each other. SIP also springs to mind. There's no shortage of usage for IPv6. I do agree that it was stupid to mandate IPsec, though.

The more relevant question is probably what has been holding it back, and it should be no secret that the answer is, as always, Windows. Since Windows hasn't, until Vista, shipped with IPv6 enabled, ISPs have had virtually no reason to implement it (I've been lucky enough that my ISP (BBB, in Sweden) operates an anycast 6to4 router, so I've been able to use my 6to4 /48 address space). Now that Vista does ship with IPv6 enabled out of the box, that may well be likely to change. That is the sole reason why I'm hoping people will switch to Vista.

I've configured IPv6 (again over 6to4) for the friends of mine whose computers I often deal with, and it has been very helpful, since it has been allowing me to bypass our NAT routers. I, for one, definitely hope that IPv6 will saturate the Internet sooner rather than later, so that I can do the same with everyone.

Last, I should admit that there's probably one more thing holding IPv6 back, namely the fact that there's no agreed-on protocol to detect local DNS servers using only IPv6's autoconfiguration. Since the autoconfiguration is another highly anticipated feature of IPv6, but still offers no standard way to detect DNS servers, it makes it uncertain how IPv6 should be deployed. Personally, I don't really understand why they can't just allocate an anycast address to the meaning of "any reachable DNS server" (or even just use mDNS). With DNSSEC, there shouldn't be any security problems with it anyway.

Re:IPv6 Needed?

[drmerope]

Now how can that be slower than v4

What you say would be true if you were using a general purpose computer to perform the routing function. In an ASIC, those added tasks are processed incrementally, byte-by-byte at wire-rate. The limiting factor is the wire-speed not the computation. Conversely, the addresses interact with a routing-table. This is usually the performance limiting section of the router. Making a hardware CAM for 128b addresses is much harder (larger, slower, more power hungry) than for a 32b address.

To make this work you either have to sacrifice the size of your routing table or your performance.

The link you cite is garbage in terms of getting an accurate handle on the practical realities of designing asic-assisted routers.

Re:IPv6 Needed?

[accessdeniednsp]

This is hugely off-topic:

But dude, I *LOVED* that sig on this post:

Karma: Chameleon (Mostly due to the fact that you come and go.) hahaha!!!11!!one

Re:IPv6 Needed?

[Gareth Williams]

Nothing. The problem with that would be... what exactly?

You do realise that the address space of IPv6 is completely insane don't you? Something like "1 address for every atom in the universe" kind of scale, I think I've heard thrown around? :)

I don't think I personally want to register more addresses than I have atoms in my body. I'm fairly confident my mother would feel the same way.

Re:IPv6 Needed?

[kasperd]

You do realise that the address space of IPv6 is completely insane don't you? Something like "1 address for every atom in the universe" kind of scale

Would have been true, if they had made each address 256 bit. But that is not the case. An IPv6 address is only 128 bits. And it is not like they are going to get assigned in small chunks. There is supposed to be assigned a 64 bit range to every single net segment. And IIRC you are supposed to be getting at least 16 bit to address the segments in your own network, which means anybody getting an IPv6 range is going to have 80 bit of addressing. That leaves only 48 bits to address each such network. So if there is going to be more than 281 billion households on the Internet we are going to run out of IPv6 addresses.

Even though that number is large enough to be pretty unrealistic, I still don't get why they didn't take it a step further and really made the addresses 256 or 512 bits. Or at least something which was guaranteed to scale to that size. If they ain't going to give every person in the world that personal /48, it means there are too few addresses, or maybe political reasons to block the usage of IPv6.

I think the real reason the change to IPv6 is going so slow is neither the complexity of the protocol, nor the number of addresses. The real reason is the not so carefully designed transition plan. I have the impression that most core routers and most operating systems already support IPv6. But creating a network of routers with IPv6 support does not necesarilly mean you are creating an IPv6 network, and I think that is why IPv6 has not gained momentum. There are different ideas on how this should have been done, but of course it is easy to point out the problems in retrospect. It is much less obvious which of the many alternative solutions would have worked. It wasn't even obvious beforehand, that the current design would not be an immediate success.

A better approach might have been to first create a system where initially only 2^32 IPv6 addresses where used, such that there would be a 1:1 correspondance between IPv4 and IPv6 addresses. The same packet could change between IPv4 and IPv6 as it was being forwarded. And routers would be required to use IPv6 if they knew the next hop supports it, or if the source or destination IP happened to be outside the range that could be mapped to IPv4. Once such a system had been rolled out to most of the Internet, it would make sense to start creating routes that could not be mapped IPv4. Once that was happening there would be a significant insentive to upgrade the remaining parts of the Internet to IPv6.

Re:IPv6 Needed?

[Gareth Williams]

Would have been true, if they had made each address 256 bit. But that is not the case. An IPv6 address is only 128 bits. And it is not like they are going to get assigned in small chunks. There is supposed to be assigned a 64 bit range to every single net segment. And IIRC you are supposed to be getting at least 16 bit to address the segments in your own network, which means anybody getting an IPv6 range is going to have 80 bit of addressing. That leaves only 48 bits to address each such network. So if there is going to be more than 281 billion households on the Internet we are going to run out of IPv6 addresses.

Ah. I didn't think of that. That's completely crazy - what's the point of having such a huge address space if you divide it up into sufficiently large chunks? Who could possibly need that many addresses?! Sh*t, there are very very few households that have more than 256 addressable devices I suspect - if you do you should probably be more worried about the power requirements than how many IP addresses you'll have :) That's 8 bits.

Sure, there are some large organisations around that'll need more, but why not allocate them larger blocks on a case-by-case basis - "if you request it, we give you more" kind of thing. Not many places that don't need it would bother to file the request.

Even though that number is large enough to be pretty unrealistic, I still don't get why they didn't take it a step further and really made the addresses 256 or 512 bits. Or at least something which was guaranteed to scale to that size. If they ain't going to give every person in the world that personal /48, it means there are too few addresses, or maybe political reasons to block the usage of IPv6.

Can you imagine what a pain it would be to type 512 bit addresses by hand? ;)
Besides, what would that solve - they'd just allocate everybody even bigger chunks!


The rest of what you said I completely agree with. The real problem with IPv6 is the same problem various good spam-fighting solutions face - the high amount of inertia involved in moving everybody from an old entrenched technology to a new & superior one can not be overcome easily, and certainly not all in one go. You need a plan to shift gradually, with inter-operation between the new & old technologies during the years of the changeover period. The scheme you described sounds pretty good.

Requiring everybody to change at the same time is damn near impossible.

Re:IPv6 Needed?

[kasperd]

Who could possibly need that many addresses?!

The reason for allocating so much for each netsegment was to allow for ways to assign IP addresses within the segment without involving a DHCP server or a configuration that had to be set up on each machine. Two of the approaches used to choosing the lower 64 bits of the address are either random or based on the MAC address. But even in that case 64 bit seems like just a bit of overkill.

Can you imagine what a pain it would be to type 512 bit addresses by hand?

You should rarely have the need to type on by hand. Besides there are short hand notation for IPv6 addresses with many zeros in them. If the addresses had been made 512 bit, but until everybody had upgraded from IPv4 to IPv6 there would only be handed out addresses in which the most significant 400 bits were all zero, they wouldn't be that difficult to type.

End to End addressing != Internet

[Anonymous Coward]

The word internet means INTER network. If you have forced end to end unique addressing then you have given up a large part of what makes the internet nice.

IPv5

[suggsjc]

They should have used IPv5 as a practice round to get all the bugs out...

Broken protocols

[Skapare]

A protocol that requires a firewall to be stateful just to allow it to pass, I would call broken. And yes, I have for years called FTP a broken protocol (acknowledging that this observation is hindsight). I'm not talking about statefulness for NAT purposes, but rather, statefulness to track permissions on related communications (e.g. the DATA connection in FTP). FTP was designed in the day when no one expected blocking of arbitrary ports. But this is something we will be doing apparently forever.

Let's fix the broken protocols and move forward. While we can use HTTP for many file transfer needs, a new protocol that conducts everything over a single TCP connection or a single SCTP session is where we need to go. Then a firewall can be simple in operation and probably more secure as a result.

Re:Broken protocols

[ciggieposeur]

Let's fix the broken protocols and move forward. While we can use HTTP for many file transfer needs, a new protocol that conducts everything over a single TCP connection or a single SCTP session is where we need to go. Then a firewall can be simple in operation and probably more secure as a result.

Oh yeah, route everything through a single TCP connection. That will make a firewall MUCH easier to implement! It will only need to examine the payload of every packet to figure out which ones are email, which are file transfer, which are P2P, which are key exchange, which are time sync, etc...

Re:Broken protocols

[Mr2001]

Doesn't UPnP's NAT traversal solve this, at least when implemented correctly (I don't know how DC++ managed to completely screw it up)? If you need an incoming port, just ask the firewall for one.

BTW, I think SFTP is the "new protocol" you're looking for.

Re:Broken protocols

[LinuxDon]

I hate to state the obvious, but doesn't passive FTP "fix" this "problem"?

Re:Broken protocols

[Tony Hoyle]

Good luck using UDP at all without a stateful firewall.

(I also don't see what IPV6 has to do with it.. IPV6 has NAT - in fact I'm glad it does - allowing your internal IPs to leak onto the internet is an information leak most companies simply wouldn't allow).

Re:Broken protocols

[Skapare]

You seem to think that this means merging all the protocols into one joint TCP connection. No ... each individual activity will be it's own one connection, which is what most protocols already do. It's the broken ones like FTP that try to do 2 or more concurrent connections at the same time in some related way, especially, going back in the reverse direction, for one activity that need to be fixed so they use just one. Thus there would be one connection for each instance of running a download session, just as there is one connection for each instance of an HTTP request, even though you can still see many such connections of each at any given time on a very busy system.

Re:Broken protocols

[Skapare]

If the issue is tracking some random return port, sure, UDP is a problem with firewalls that requires statefulness to workaround. UDP is broken, too. SCTP can do a lot of what UDP wins over TCP on. Things like DNS should be handled separately, anyway (e.g. the firewall does DNS caching and lookup serving).

Re:Broken protocols

[Skapare]

Actually, no, SFTP is not what I am looking for. Sure, it would work over a stateless firewall. But it's an ugly hack that doesn't lend itself to anonymous file serving. A new clean protocol is need to replace FTP (and it could replace HTTP, too).

Re:Broken protocols

[Mr2001]

Aha. Well, how about just deprecating "active mode" FTP and switching everyone over to passive mode?

Re:Broken protocols

[ciggieposeur]

You seem to think that this means merging all the protocols into one joint TCP connection.

I think that because that is what you actually said. If you meant something different you should have said something different.

If you meant to say that protocols should not span multiple ports, then you're not asking for anything that isn't already implemented. FTP is dead due to the cleartext passwords, so people now use HTTP and SCP/SFTP to move files around.

Re:Broken protocols

[Skapare]

I think that because that is what you actually said. If you meant something different you should have said something different.

So you are taking things out of context. How does "... a new protocol that conducts everything over a single TCP connection or a single SCTP session is where we need to go" indicate that the single TCP connection or single SCTP session (I meant to say association) spans multiple instances. A valid statement is "SSH conducts everything it does over one TCP connection". It can do quite a lot over that one TCP connection. It can forward other port traffic, too. But, there is nothing in that statement that says all instances of SSH jointly share the same connection, or that separate instances of SSH cannot have separate connections.

Of course I did not explicitly say that separate instances get separate connections. I shouldn't have to for the Slashdot audience. If you know protocols reasonably well, you should understand the context.

As for not spanning multiple ports, that doesn't even have to apply. A protocol could be designed that would make related connections for the same instance but do so over the same port number on one end (as long as one of them is different it makes the the connection distinct even if both IP addresses are the same).

End of context lesson. If you can't grok it by now, it's a waste of my time going any further with you. I may have the time to come back and read a final reply, but I won't spend the time to make another reply of my own.

I'll continue to work on my new protocol for file exchanging that, among other things, have all that is needed for replacing FTP, HTTP, and RSYNC (and maybe even NFS), do so securely, work on top of your choice of SCTP (the design target) or TCP (legacy support mode with emulated streams), and have no limits on size of file or length of names (but it will include graceful handling of administrative policy limits).

Re:Broken protocols

[Skapare]

Depricating active mode would be more usable over firewalls. But for many reasons, it's still time for FTP to go. I'd replace it with something that is fully secure.

Re:Broken protocols

[hartz]

UDP is connectionless - the ability of a firewall to do stateful filtering is irrelevant as far as UDP packets are concerned.

Gaaaah!

[mikeee]

The problem with NAT and firewalling, both, is that they're broken by design. They're attempts to add features to the protocol/application/OS layer that are implemented at the network layer. It doesn't have the necessary information to do the job properly! So we end up with godawful mostly-kinda-works klugdes like timeouts on idle TCP connections, etc....

I spend a fair bit of time tracing down network-related application issues, and let me tell you, NAT and firewalling are the work of the devil. Look, I'm all for a Linksys in front of your home Windows box, but please please, can't we kill this nonsense off once and for all?

No?

(pounds head on desk)

Security by obscurity doesn't work

[Moraelin]

Sorry to rain on that parrade, but the (variants of) "IPv6 is secure because it's a 64 bit space and noone will ever guess your address" sound... surrealistic. It's security by obscurity of the worst kind. The kind that can't possibly work.

We live in an age where far larger combinations of bits -- e.g., email addresses or name/password combinations -- are sniffed, phished, compiled into lists and sold, etc. What on Earth makes people think that a fixed IPv6 address would be more secure? No, honestly, what's so special about an 8 byte IPv6 address that makes it un-sniffable?

The notion that your machine is only findable by raw brute-force scanning is pretty laughable. Yes, it's one of the easiest and most non-brainer methods, but it's not the only one.

As a counter-example, look at how email viruses work. Because they _do_ work without scanning and without looking for you speciffically. They just go through more hops, each hop sending itself further to everyone in your address book.

Guess what? The exact same can be trivially adapted to an IPv6 worm. Each pwned machine just continuously looks for incoming and outgoing connections, and tries to spread to those too.

Or how about lists of static addresses, the same as the lists of email addresses that spammers buy and sell. Only unlike email addresses, if you're unfirewalled, you can't keep yours secret. You _have_ to tell each visited site your address every time you connect to it, so it knows where to send the response packets.

So basically it's the setup for the easiest kind of phishing imaginable. It's like automatically giving your email address to every site you ever visited, except this time it's your IPv6 address. Someone just has to create or pwn a popular site, and just record all the IP's that connect to it. Voila, that's a nice list to sell to the hackers. No more brute force scanning needed.

We already have major corporations whose computers are spam bots. What makes you think none will host IP recording bots? How do you know none of the ecommerce sites or forums you visit could be pwned to record all those static IPv6 addresses?

Or it just takes one bored intern working at a major ISP to run a sniffer and get a huge list of all static IPv6 addresses that sent or received anything through their pipe. Remember, idiots exist everywhere. One guy sold the whole list of AOL addresses to spammers, for example. So are you _sure_ noone will sell the list of allocated/known IPv6 addresses?

And since it's static addresses (after all, the whole idea is to get rid of NAT, right? No more dynamic addresses and remapping, right?), you know that each address logged will be available for a long long time thereafter.

Basically let's stop using the whole "we're secure by obscurity" concept to rest already. If there are other security mechanisms in place, fine, I want to hear about them. But "noone will find your IPv6 address" is _not_ security. If you want to talk security, you start from the most paranoid scenarios imaginable, not from wishful thinking.

Re:Security by obscurity doesn't work

[kebes]

Everything you've said is true...

However, I don't think the argument is "the large IPv6 address space provides robust security" but rather "it's an extra roadblock to attackers."

Switching to the large IPv6 address space doesn't mean that we can get lazy with patching our boxes, surfing safely, blocking ports, having strong passwords, and so on. However, it does mean, at least, that one vector of attack (port scanning) is no longer possible, or at least very difficult.

All the workarounds and attacks you describe are certainly possible, but they mean extra effort on the part of the attacker, which induces a corresponding decrease in the frequency and success rate of attacks. And it's worth noting that in addition to the workarounds that the attackers will no doubt employ, there may very well be some clever usages of IPv6 to counter them. For instance, if I'm in control of 10^20 addresses, I may run my web browser from a VM whose IP address changes on every connection. So knowing the IP of my web-browser doesn't give you the IP of my file server, etc. Similarly the 10^20 - 4 addresses that I'm not using can be a very efficient honeypot for detecting attackers.

To re-iterate: the large address space of IPv6 should not be viewed as "killer security"... but nor should we ignore that it will provide a (arguably minor) security advantage.

Re:Security by obscurity doesn't work

[MajroMax]

The notion that your machine is only findable by raw brute-force scanning is pretty laughable. Yes, it's one of the easiest and most non-brainer methods, but it's not the only one.

And on a dense IP space like IPv4, it's also the fastest method of scanning and spreading. For a worm propagating in its initial phases, its rate of growth is determined by how many "hits" it gets over N probes. By moving from IPv4 to IPv6, the search space goes from "very dense" to "highly sparse". If the worm still propagated by random probes, its growth rate would decrease by a factor of ~ 2^96 -- to essentially nil.

This means that a hypothetical IPv6 worm would have to use some sort of passive scanning. This algorithm is much harder to implement, and it also implies that there must be a continuous connection path for the worm to spread. Since, for example, web connections (between servers) are isolated (foobar.com does not talk to yahoo.com does not talk to google.com), this implies that entire categories of worms are essentially impossible to develop.

Re:Security by obscurity doesn't work

[ivan kk]

IPv6 addresses are 128 bits, not 64.

Re:Security by obscurity doesn't work

[maop]

Sorry to rain on that parrade, but the (variants of) "IPv6 is secure because it's a 64 bit space and noone will ever guess your address" sound... surrealistic. It's security by obscurity of the worst kind. The kind that can't possibly work. Actually it uses 128-bit addresses. Not that I agree that security through obscurity is a good thing.

Re:Security by obscurity doesn't work

[WuphonsReach]

If the worm still propagated by random probes, its growth rate would decrease by a factor of ~ 2^96 -- to essentially nil.

It's probably a lot lower then 2^96.

From my (vague) understandings of the IP6 address structure, there are a lot more "unused" areas. So that may cut it down to 2^80 or even as low as 2^64. And if all of the older devices live in the IP6 to IP4 conversion address range... a non-discriminating infecter may choose to start there first.

The other half of the equation is that we're no longer in the days of 56kbit leased lines. Now, a lot of infected machines have much larger pipes (512kbit up to 5mbit), which means that they can scan 10-100 times faster then in the old days (which is another 2^6 off of the 2^96 number).

IMHO...

translation

[Anonymous Coward]

some ACLs on your routers Or as we say in the trade, a firewall.

ACL stands for Access Control list... firewalls are devices that control access - most commonly this control is implemented in a routing node.

NAT is bad

[nsayer]

If you take the firewall out of the equation, there is still one bit of evil left with NAT - applications that may want to set up and announce a listening port don't know what the correct IP address is. Often times they have to resort to bizarre workarounds, like asking a known external service what their own address is. Very byzantine. If nothing else, moving to IPv6 removes that headache. And if you have two machines behind a 1:n NAT that want to open up port 80, you're hosed. Without NAT, that's not a problem anymore. You'll have to tell your firewall that connections to port 80 on those machines are OK, but that's nothing more than what you would have had to do to your NAT box anyway (except that one of them would have to be port 81 or 8080 or some such nonsense).

I can't wait for the home networking routers that are so popular to implement 6to4. There's no reason they can't do that right now. Even if it were off by default, having it there would give people more options at little or no cost to the manufacturers. All of the major OSes out there shipping today support IPv6 natively.

One word:

[Kadin2048]

What'sdriving it now that wasn't driving it five years ago?

SIP.

Right now, most people haven't run into it, but there's no easy way to have multiple SIP VoIP "lines"* into your house, when you only have one IP address.

* I mean "lines" in the POTS sense, of independent full-duplex telephone circuits, each with their own numbers. And yeah, I know you can get this if you use protocols other than SIP, but they have their own problems.

Re:One word:

[glomph]

This is just plain FALSE. I have numerous SIP registrations coming from home, without using STUN. It works. One IP number.
I have this going on about 5 servers, each with several SIP registrations (often to the same service) in place.

SIP is idiotically complex, that is why IAX was invented, which all happens on one port.

But the people writing clients, servers, and client/server combos (eg Asterisk) are actually more clueful than
the vested interests that keep pushing IPv6 to a disinterested world. IPv6 reminds me of the Bell System's Picturephone, which
I used decades ago. It worked fine. Many other video-phone solutions exist. The bottom line is, there's no screaming need for it.

NAT is here to stay, just as is substandard overpriced 'broadband' service, at least here in Freedomland.

Re:One word:

[Vancorps]

huh? That answer makes no sense, that's like saying you can only have one ftp client at a time connecting through a public IP address. I routinely have not 2 but 10 SIP phones communicating over the Internet back into my home office without a problem. You have your control port and then you have your dynamic port which is opened to accomodate the data transferring back and forth.

I'm not sure which SIP phones you're talking about that don't support NAT traversal. You might have had a point with H.323 but thankfully that is dying.

As far as the number of lines, thats limited by the number of ports that can be opened. The only advantage to IPv6 in this sense is that I could service more lines over the Internet by associating additional external address with my servers, but if I have that many remote users they are probably at a temporary site which would then have a PBX on-site they could connect to.

I think the real answer is that nothing is really driving IPv6 deployment since most companies don't want their internal computers to have external addresses. Securing it would not be trivial although a lot of methods that are employed for securing servers with external addressing could be deployed for workstations but that is a few orders of magnitude harder to setup.

Re:One word:

[nevali]

No; the only reason SIP works through NAPT now is because vendors got together and implemented lots of dirty hacks to make it happen. SIP as specified assumes that there is no translation going on, and that the local IP is the same as the source address in the packets that the destination will receive.

The fact that SIP had these problems from the outset is part of what made Skype so appealing: when Skype was launched, SIP setups were pretty much a no-go by the vast majority of consumers. Now, thankfully, things are a little different, but vendors had to work around the problems inherent in the SIP protocol to overcome that.

Increasingly, telcos are using SIP for trunking (where NAT/PAT/NAPT issues don't actually affect them on their own core networks), but I'm led to believe that newer implementations of H.323 are starting to emerge at the edge which cope far more effectively with NAT than SIP ever has.

Re:One word:

[Vancorps]

That was all in the past and technological hurdle has longed passed. At least with our Televantage setups we don't have any issues with NAT and having phones operate effectively. It seems to be more of an issue with phone support than a problem with the protocol itself. From my experience SIP is very flexible much like TCP/IP that means its not always the best choice but it wins because it is the most supported. H.323 is dying and rightfully so, it had a lot of problems behind NATs as it required a multitude of control ports that couldn't be effectively remapped. Of course now modern firewalls support SIP transformations so the issue has been solved and is no longer a problem for modern deployments. All of our trunking is SIP until we hit our PRIs and we've not had one issue is now a year of operation, not even during setup.

I had thought Skype became popular because it allowed people to call other people for free and it was very simple to use. Of course I've never used it as I've never needed to. SIP has come a long way over the last few years and especially in 2006. With Exchange 2007 supporting it things are only going to go more in the direction of SIP. Of course Exchange 2003 supports SIP too so that says something as well. I don't think NAT traversal is near as big an issue these days as it was even four years ago.

Re:One word:

[Anonymous Coward]

Right now, most people haven't run into it, but there's no easy way to have multiple SIP VoIP "lines"* into your house, when you only have one IP address.

At the moment I work in a small office with ~20 SIP-phones all NAT'ed to one external IP. The NAT-device is is just a simple Linux-box doing nothing special. No problems so far!

Can most people avoid NAT?

[misleb]

Even with IPv6, I wonder if it will be practical to ditch NAT at home. Assuming (like the TFA does) that people will continue to use firewalls and/or wireless routers, how is one going to route one's subnet to the inside of the firewall? I would guess that most common residential ISPs are NOT goign to be very keen on setting up special routing arangements with you. You'll get your IPv6 subnet bridged across your modem and if you have a firewall, you'll pretty much have to do NAT to traverse the firewall at all. Sure, you'll be able to use one-to-one NAT, but it is NAT all the same and still causes some problems.

-matthew

IPv6 offers that.

[Kadin2048]

You wouldn't need to. IPv6 has the capability of having temporary addresses, where the client machine basically generates the last few bits (actually quite a few) of the address randomly. You can swap these addresses as frequently as you'd like (well, it will probably do Bad Things to the upstream routers if you change them too quickly, and it might be considered abusive at some point) in order to retain a level of anonymity that's greater than or equal to what you have with IPv4+NAT right now. (It's still not true anonymity, and isn't a replacement for systems like Tor, but it would make it close to impossible to figure out which device on your LAN the traffic is coming from, without compromising your LAN's router itself.)

You might want to read this document from the IETF regarding privacy and IPv6. Ensuring privacy, or at least not eliminating it, was a major concern of theirs during the design of v6, and I think you'll find that your privacy is protected just as well or better than it is under IPv4 (which is to say, not really all that well, but if it gives you a warm fuzzy feeling to think so, enjoy).
http://playground.sun.com/ipv6/specs/ipv6-address- privacy.html

Therefore, in the future IPv6-based Internet, we expect many devices to have two kinds of IP addresses:

        * Unique, stable addresses, assigned in any of several possible ways (e.g., by manual configuration, by an address server like DHCP, or by auto-configuration using embedded, factory-assigned LAN addresses), for the purpose of being a target, and for use when initiating communication to other, trusted targets, such as targets within the same home or enterprise.

        * Temporary, transient addresses, such as those containing a random number in place of a factory-assigned serial number, for use when initiating communication to less trusted targets, such as public web servers.

The choice of which kind of address to use when initiating communication is somewhat analogous to the choice that must be made when placing a telephone call in the presence of the "Caller ID" feature, i.e., whether or not to reveal the calling party's number to the called party. IPv6 addresses offer both choices.

Re:IPv6 offers that.

[FreezerJam]

"it would make it close to impossible to figure out which device on your LAN the traffic is coming from"

I want a stronger condition than that. I want it to be impossible to count the devices on my LAN. Random bits might make it impossible to count, but they also appear to reveal a lower limit on the number. In other words - by monitoring the IPv6 address stream, I can't tell if you have 5 devices or 500 devices - but I know you have at least 5. I don't want my devices to appear to be *more* devices - I want them to appear to be one.

To send anything, I need at least one device. I will admit to having one device. But sending information that implies something about the number of devices I have connected is needlessly leaking information about my network topology. I want all my devices to emulate being "one device", so that nothing about my network topology is revealed.

Re:IPv6 offers that.

[someone300]

Not quite, if you have had data sent from 5 unique IP addresses, it could all have originated from the same device. There is nothing revealed about your network topology.

Re:IPv6 offers that.

[Tony Hoyle]

Send out an LLMNR broadcast. Instant topology. That's the whole purpose of it, so you can discover network services on an ipv6 network.

Broken Protocols

[hweimer]

The problems don't come from having NAT or a stateful firewall, but from using poorly designed protocols. There is hardly a justification for using more than one TCP or UDP port, or dynamically assigned destination ports.

For example, compare IPSec with OpenVPN: the former requires various UDP ports plus a completely new IP protocol, while the latter runs over a single UDP port. Now guess which one is much easier to get through a firewall.

I guess I'm slow. Please help me out....

[Anonymous Coward]

"Not having a firewall isn't as huge a deal as the Cyber-Alert suggests: the only thing that happens is that packets from the Internet are delivered to computers connected to the base station, a situation which is no worse than what happens with dial-up or when connecting a computer directly to a DSL or cable modem."

Correct me if I'm wrong, but people who connect a computer directly to the Internet via DSL or cable modem tend to have their PC's trashed or turned into zombies. The author claims that M$ firewall is good enough to defeat any exploit thrown at it, with no extra support. I don't buy that. I use ZoneAlarm, and a bunch of other software to protect against what gets past the firewall via HTTP or whatever. That's after my wireless router has filtered a bunch of other trash. At work, the admins don't have (won't make?) time to carefully layer in defenses on every PC. They use the M$ firewall, thrown on Norton Anti-virus, and depend on the corporate firewall.

This sounds like another situation where ivory tower types are whining about the real world. To me, the first step is to rethink the no-NAT concept. NAT provides privacy as well as security. I don't think the corporation I work at wants the world to know the IP address of every packet originating inside. I would think by now that even the secluded scholars would have realized that security and privacy are huge issues in this increasingly connected world.

obsession?

[nurb432]

In todays world its not safe to connect to the outside world without one. I dont see 'safety' being an 'obsession'.

Especially when 1/2 our house is run on an internal IP network. i DONT want someone managing to turn off my heat or something..

Re:obsession?

[rts008]

Hear! Hear!

I for one do not want V1AGRA spam 'popping up' from my toaster!

HOST security NOT network security!

[Danathar]

I'll probably get flamed big time for this but it's my opinion that the application and OS Vendors have done a great job in fooling the world for a LONG time. Basically they've weaved a magic spell that has convinced the world that managing security is primarily the job of the network (hence network security).

Problem is, for the most part the network is not insecure (sans router vulnerabilities). The networks do what they are supposed to do, transmit packets. The security problem is with each HOST on the network. The OS and application vendors have convinced us that your first line of defense is the network firewall which for a LONG time has let them off of the hook.

If the OS's and applications were reasonably secure, the need for a firewall and/or NAT device would be MUCH less. Firewalls cause problems with applications. The only reason we use them now is because the security risk at the HOST level is SO high nobody can risk leaving these systems on the network.

Because of stuff like EULA's nobody is able to hold the OS vendors and application developers accountable for shipping products that are insecure.

I should not have to build a mote around my castle because I can't buy castle walls or doors that are reasonably effective.

Multiple reasons.

[Junta]

Well, for one, an administrative account may set up firewalling rules on a box to overrule attempts made by a normal account to open listening sockets (mitigate a number of attacks that rely on users running exploitable network apps or certain opportunistic attacks that listen for a queue to give a third party access). Performing a function along the lines of 'chown' for ports. The way many applications are written, unfortunately, implementing a more obviously chmod-like facility for ports in which the process impacted is made aware of the other layers policy, many existing applications would break.

A good example could be synergy. Let's say I'm a user interested in the program. I'm semi-lazy so I like the quicksynergy front end. If you ever use synergy, you know that it doesn't in and of itself bother with meaningful authentication or encryption. Also, while the daemon itself supports being explicit in terms of which IP interfaces to bind to, the quicksynergy frontend does not expose the relevant configuration options. So while I know how to make use of ssh to port forward and authenticate for me, out of the box I still may leave synergy hanging out accepting any connections on the IP network. Considering synergy could effectively be a means to do keylogging (if user accidently moves mouse to wrong place for example), this is highly dangerous. Now, my distribution being fairly restrictive had placed hard and fast firewall rules in place to only allow blessed applications access in, except on lo. If I wanted to shoot myself in the foot with synergy, I'd now have to jump through some hoops and hopefully in the process learn why it's a bad idea. There probably exist poorly designed but useful network daemons that don't even allow interface-specific binding, in which case firewall rules bridge the gap. You can't always shut down a process that does foolish things in terms of listening on sockets you don't like without configurability to get around it, sometimes you need that process to run and the network to be denied by a layer the process can't mess with and even is unable to absolutely confirm exists.

Yes, well-written applications should not do inappropriate things with listening sockets without the ability to lock it down. However, the world is full of not-so-well-written applications. The key is letting those apps think they are doing what they want with the firewall ruleset under the covers establishing the reality in ways the application cannot see or change. Good frontends for 99% of usage out there exist (OSX I believe makes it obvious when enabling a service it is also futzing some firewall rule to complement that, so it is intrinsically linked in the dialog most anyone will deal with).

This is one aspect where I disagree with Ubuntu philosophy. Ubuntu philosophy is along your lines (don't bother with iptables rules by default, they just get in the way and the user knows what they are doing). This seems incongruous with the whole mission of linux for the masses that Ubuntu is about.

IP6 != IP4

[wowbagger]

IPv4 sites can be accessed with IPv6; IPv6 addresses include IPv4 addresses as a subset.

That's like saying "My car can RUN on diesel because I can put a can of it in the trunk."

I will tell you what: if what you say is true, then you should be able to retrieve the front page of Slashdot using HTTP over TCP using IP6 headers rather than IP4 headers. Why don't you give it a try, watching with your favorite packet logger, and post the results.

Yes, IF:

• Your computer has an IP6 stack.
• Your ISP handles IP6 datagrams.
• Slashdot's server have IP6 stacks.

THEN you might be able to do IP6 from your IP4 address to Slashdot's IP4 address.

BUT if ANY step in the way cannot handle IP6 datagrams — even a step as lowly as the cheap router your ISP gave you, or the cable modem head end unit, or .* — you WILL NOT BE ABLE TO USE IP6 DATAGRAMS.

Congrats.

[Kadin2048]

I said "no easy way," not that it's completely impossible. You can do it, but traversing multiple SIP connections over NAT with a single public-facing IP address is almost stupidly complex and/or requires specialized SIP-aware NAT hardware, and it's far beyond what most people are capable of doing, just for the static case. I don't even want to think about the case of roaming wireless SIP clients, which is really the goal.

IPv4 is going to die, and NAT along with it, it's just going to take a very, very long time. The main problem with IPv6 has nothing to do with its core functionality, the problem is that it had a serious case of featureitis (e.g. IPSec); if the IETF cut out the crap and just let people implement the long addresses without the rest of the stuff better left to the application layer, it would probably get implemented a lot faster.

Re:Congrats.

[glomph]

Still incorrect. I am using NO special hardware or software anywhere. Just run-of-the mill Asterisk, some behind NAT and sone not behind NAT. 2 years ago, it was very iffy about this stuff working. Now it always works.

If somebody (it will happen) could free up some of that famous wasted Class-A number space, IPv4 will live well beyond my time.

I totally agree on the 'cut the crap' comment you offer.

My stateful ipv6 fiewall rules

[cms108]

This lets me route all of my million billion zillion ip addresses in my /48 with no NAT and no inbound stuff allowed at all unless initiated from the inside.

block in on pppoe0 all
pass out quick on pppoe0 proto tcp/udp from xxxx:xxx:xxx::/48 to any keep state
pass out quick on pppoe0 proto ipv6-icmp from xxxx:xxx:xxx::/48 to any keep state

Whew... That was really hard to set up.

NAT is excellent and should be kept at any cost!

[BobMcD]

I'm sure no one is reading at this point, but NAT is an awesome thing. I demand the ability to run a private, non-routable-by-design network that can still cooperate with the outside world. It's been said here lots, but let's run down the advantages:

1) Ease of use. NAT's 'firewall' features are on by default. My mom has a firewall, because she has NAT. Zero extra config required. Show me that on IPV6 and we'll talk.

2) EASE OF USE!!! When my brother brings his lappy over, do all the routers in the world need to now know that he's behind a different hop? Why can't he just grab DHCP and be ready to roll, sharing one of my already-configured addresses? Enabling world-wide access to every internet ready device isn't practical when they readily can move around...

3) Privacy. Do I have one box behind my cable modem, or ten? Does my ISP really have a right to know? What about the RIAA? Should I now have to pay to reserve some extra IPV6 addresses in case I want to expand my network at some point? With honeyd or similar, I can make it look like I'm running 1000 boxes back there, and with NAT those addresses are at ZERO COST to anyone else.

4) Nullification of Point. Not every device in the world needs a unique address. In fact, it benefits us that most do not. Should someone interested in pin-pointing specific traffic behind NAT use a silver bullet against my firewall, they'd still need to know which internal address they're going after. Likewise they'd better not be using that same address space in their local routing table. The scenario is considerably more complex, and from a security/privacy/no-I-dont-feel-like-sharing-with- you point of view, this is a really good thing. With world-routable addresses for everyone all one would need do is remove the barrier. Poof! Instant access. Now our unique addresses aren't such a good idea.

I'd like to join those suggesting what's likely to be the natural result of all this anyway:

IPV6 is for routers. Give my half-a-dozen addresses, let me bind them to the outside of my firewall, then I'll map them back via NAT to my IPV4 space. Everyone wins!!!

And to those discussing Virtual Machines needing IPV6, I say the opposite might be better. If you're splitting them behind a single interface anyway, why not NAT the addresses back at that point? Then the only 'attackable' services are those you've opened via NAT. The rest of the world would see one machine offering a host of services, when in reality you're running each of those services in a unique environment. If you need to overlap ports, THEN use another unique address.

Umm....

[vonsneerderhooten]

Isn't this why most of us have jobs?

Software firewalls

[Anonymous Coward]

Poorly written software firewalls will continue to ruin network connection quality well into the future regardless of the network architecture or protocols in use. Multiplayer gaming has grown worse and worse as these evil products proliferate. Worse still, the majority of them provide a false sense of security and open additional vulnerabilities, besides just adding lag and raping the connection quality overall.

As long as people insist on looking for "free" porn, music and videos while using popular operating systems then garbage software firewalls will continue to flourish. The only solution is physically separate networks. Keep all the free porn hound suckers on the main internet (now mostly useless), and build physically separate networks with specialised architectures and protocols designed for the tasks at hand. That way gaming and work can continue while the mindless fools can continue running the original internet into the ground.

It is the only solution, you know it is true.

Re:NAT is excellent and should be kept at any cost

[Anonymous Coward]

1) How's that different from a "block in all" default rule on the router? Keeping state in the firewall is fine as long as it is bounded by the outgoing traffic (because that's limited). In fact, if you reset the firewall, it is a lot less dangerous, because almost all protocols have some kind of ACK mechanism, so for active connections the internal machine is likely to resent to the outside. That means the firewall can rebuild the state table based on that.

2) Do you have any idea how IPv6 actually works? Neighborhood discovery and route announcement give you an address and a next-hop. If needed, DHCPv6 gives you e.g. the nameserver as well. Mobile IPv6 can allow him to use his home network.

3) This is just bullshit. For Vista, the privacy "extension" is active by default. Basically, just assign two addresses -- one for internal use and one for external use. The internal one is derived from the MAC, the other random. You can just recreate it every bunch of minutes as long as you want.

4) OK, this is the final proof that you are clueless. Any communication needs a unique identifier for src and dst. NAT makes it unique based on (src,port), (dst,port) -- so what? It just makes it more complicated for no good reason. Remove the barrier? Like hacking a machine either in the inside network or the firewall? How is that *any* different from many of the attacks already in use?

FW vs Router

[Anomalyst]

The difference between a router and a firewall is primarily the default intent:

router: do your darnedest to forward any traffic not specifically denied. A poorly configured ACL can leave you swinging in the breeze. Logging is usually off by default.
Fer instance: a ping sweep on a default setup will expose all hosts active and responding and log nothing about someone rattling your doorknobs.

Firewall: do your darnedest to block anything not specifically allowed. A poorly designed ACL is less likely to be unsafe. Logging of violations is usually enabled by default.
Fer instance: a ping sweep on a default setup should not reveal any hosts but should log the sweep attempt.
In a pinch, with some extra effort and understanding, you can configure a router to behave like a firewall and vice versa. You can use a screwdriver as a chisel too, it's just not the correct tool for the job, if you want consistent, professional job.

Assumptions about what "firewall" means

[Anonymous Coward]

Why is it that "firewall" is always assumed to be a packet filter, regardless of whether it's stateful or not? Some of the toughest firewalls I've seen were proxies, i.e., the client never actually talked directly to the server; they talked to a fully-protocol-aware proxy instead. (Yes, performance sucked, but try getting a stack-smashing attack through.) IPv6 is designed to do end-to-end, and firewalls (packet filters or proxies, stateful or not) break that model. However, I'd argue that's by design.

Ah, well..... Rather than bitch about it, I'm planning to deploy IPv6 on my home network, then study it and the effects of firewalling on it first-hand, probably while drinking a shitload of beer. What are you planning to do?

I have no problem with that

[Moraelin]

We're going to aggree there very quickly. I have no problem with seeing it as an extra road bump. That's a sane and realistic attitude, and every bit helps, obviously.

However the argument does end up again and again being, basically: "if we were finally on IPv6 you could really give up all firewalling and defense, since you're impossible to find in all those gazillions of possible addresses anyway." Now probably no serious admin would think it's security, but somehow just that claim does seems to pop up on Slashdot every time IPv6 is mentioned. I've seen half a dozen messages to that effect in this thread alone, and that just skimming through it.

Now maybe they had something more along your assessment in mind, but any details were missing that would hint that way.

Re:I have no problem with that

[locofungus]

We're going to aggree there very quickly. I have no problem with seeing it as an extra road bump. That's a sane and realistic attitude, and every bit helps, obviously.

It's more than that. It makes the current type of worm/virus/whatever that spends its time scanning for more machines to infect pointless and worthless.

Count how many "hits" you've had from random port scanners on all ports in all the time you've been connected to the internet.

Divide that by the difference in address space size between ipv4 and ipv6 and in an ipv6 world, the number of hits like this will be zero.

You're still vulnerable if an attacker knows you are there.

ipv6 may become an excuse not to upgrade vulnerable services (which is bad) but currently our bigger problem is that most people don't upgrade vulnerable services at all and those of us that do are quite literally[1] being drowned out by the people who dont.

[1] I had a machine DOSd off the internet by another persons machine on the same subnet that, once it was infected with one of the SQLserver worms, proceeded to overload the router with its scanning for more hosts to infect.

The ability of a wide spread 0-day vulnerability to scan and infect every vulnerable host on the internet in a few minutes (or even a few millenia) will have gone.

Tim.

I think this discussion is misguided

[einhverfr]

First, stateful filtering is stateful filtering. Although NAT's have to be stateful in some way, they are not stateful filters by themselves as you correctly point out.

However, ipv6 has a major change which can cause massive headaches for firewall administrators: IPSec is now mandatory. IPSec provides two optional means of security: AH (which provides antitampering) and ESP (which provides encryption and antitampering). Neither of these were designed to pass through a NAT. The reason is not that NATs are bad design but rather that they break the end-to-end security that IPSec offers (i.e. any packet tampering invalidates the packet, and NATs by definition tamper with the packets).

Sounds all right so far, but with ESP, the entire payload is encrypted. This means that a party in the middle cannot evesdrop on the connection (including the TCP headers). You don't know what ports are involved. You just know what two computers are involved. If you try to use FTP over an ESP-protected connection, however, the firewall will not be able to determine the state of the data connection. Same with H.323 (though I for one welcome the death of any OSI-decended protocol). In fact H.323 would become essentially impossible to allow via ESP to arbitrary hosts without opening up the whole network because of how the control protocol works.

Hence you run into stateful filtering issues with ESP which are not possible to sort out. In practice, you have the choice of simply allowing ESP as a protocol or not allowing it, or possibly allowing it to a whitelisted set of end-points.

Oddly enough this was not discussed in the article, which seemed to spend way too much time confusing NAT and stateful filtering.

The real risks (if any)

[sjames]

NATing firewalls serve two security purposes and several non security purposes.

The non-security purposes are to multiplex routable IPs so that we don't have to have a public address for each network capable device. That's critical in IPv4, but irrelevant for IPv6 in the forseable future.

The other is so that we can arbitrarily assign IPs to LAN devices (often with DHCP) and be happy. Auto-configuration in IPv6 renders that irrelevant as well.

Now to the security purposes. First and foremost, they provide a default condition where incoming connections are summarily blocked while outgoing are permitted (after NATing). UDP is often configured similarly so that an outbound UDP packet opens a hole for replys to come in through (also after NATing). There is absolutely nothing in IPv6 to prevent the same rules from being configured minus NAT. As a side benefit, without UDP NAT randomizing the port number, two machines behind different firewalls may request a hole by sending UDP packets out iff the firewall is configured to permit it.

The second purpose is to obscure the structure of the LAN behind the firewall including the number of machines on the LAN. It is notable that with IPv6 autoconfig it is entirely possible to find out how many devices are behind the firewall and who made the network devices.

The real question is how valuable is obscuring the addresses of the machines on the LAN and how strongly does NAT guard against leaking that information.

My guess is that NAT doesn't really do a lot there. If the firewall is well configured, most attacks behind it will be the result of users getting viruses and trojans from email and web browsing. A well crafted trojan can easily phone home using an outbound (permitted by NAT) connection and tell the attacker all about what's behind the firewall anyway. The trojan can then act as a socks proxy and allow the attacker to effectively have a machine inside the firewall anyway.

In short, there's no reason for NAT at all in IPv6. Any real security benefits to NAT are side effects of it's primary purpose and easily enough implemented properly as security rules to provide security. Network security SHOULD be a process of adding deliberate and considered rules to a firewall. It should NOT be an ill-considered side effect of solving an entirely different class of problem.

The real question is how much do those firewall rules spoil the idea of everything having a routable address. My opinion is not all that much. A firewall is simply a sort of rules server device that offloads filtering (ideally as a first line of defense backed up on the machine being protected) and centralizes policy, even in the face of mis-configured machines. Those rules would (hopefully) still be there without the firewall (who wants random people sshing or VNCing to their desktop machine), so the effect is more or less nil as far as routability goes. After all, even servers running without a firewall are often configured with hosts.(allow|deny).

The IP limitation is commercial, too

[snowwrestler]

The IPv4 address limitation is partially driven by an address shortage, but it's also a way to limit bandwidth usage. Many ISPs still have written prohibitions against sharing the WAN connection among more than 1 or 2 computers. For a while there some big ISPs (cough, Verizon) even prohibited wireless access points or routers that were not rented from/provided by them.

NAT routers hide this multi-computer usage from the ISP, which is one reason they became so popular with consumers. They let people share the connection without paying a multi-computer fee. Today the no-sharing clauses are typically only exercised when an ISP see a ton of bandwidth usage it wants to cut off.

IPv6 or no, I think ISPs will continue to limit the address space available to their subscribers. It's a way to manage bandwidth, and it can be a money-maker--if someone wants a block of addresses, that's a value-add and it costs extra. It doesn't matter that there are a billion free addresses in the space. Because the end users still have to get them from an ISP, from the end user perspective the degree of scarcity will not necessarily change.

Identical Devices

[flyingfsck]

Here is an example that needs NAT:
Say you wish to produce and deploy 1000,000 rather complex but otherwise identical systems that are mobile and can be moved around at will.

Example: Armoured cars, ATVs, Tanks, Aircraft, Helicopters, Ships, Boats, Submarines, Motor cars, Jeeps, Trucks...

Firewalls the next big business model?

[woolio]

The firewall required to do this isn't any less complex than a current NAT/stateful-firewall, but it provides several advantages. Rather than having only one externally-facing address for the entire LAN, and routing traffic based on the port or TCP connection, you can just route based on the IPv6 address, and create all sorts of (in)flexible rules based on how much trust you have in the destination device, which can include creating further subnets that are isolated from each other, for security purposes.

Interesting view. I've always considered using NAT and having only one external IP to be a huge advantage. If I have another machine/device (e.g. friend's laptop, new PDA, etc), I don't want it to be visible to the Internet.

I think most cable/DSL users (at home) have their computer connected directly to Internet, with *maybe* a software firewall (such as the one built-in to XP). If it is possible in any way for them to connect multiple devices (laptop, PDA, phone, desktop) into their adsl/cable modem without a firewall, *THEY WILL FIND A WAY*.

If IPV6 gives everyone their own block of ~256 addresses, then perhaps NAT routers could go off the market... Or what if DSL/Cable operators decide to charge a small fee for each IP address? (Not the high fees for IPV4 addresses, but something that might make that new PDA incur a small recurring or *monthly* charge)

Doesn't big business crave these tiny monthly fees that they can lure people into? All they would have to do is to integrate the IPV6 firewall into cable/adsl modem. This would have two advantages:

1) (Foolproof) Prevent users from connecting insecure devices directly to the Internet.
2) Open a new business plan where the internet operator can decide what devices/services the user can plug into the modem. (If NAT is dead, then most [unskilled] users will be stuck with this).
3) [disad] The Federal govt could assign IPs to each person or device. E.g. They would create a database of which user and which devices had which IPs.

Yes, the average slashdotter will find a way to do his own NAT. But if these devices leave the commercial market, the general public will be subject to the whims of the ISPs.

Re:Firewalls the next big business model?

[WuphonsReach]

I think most cable/DSL users (at home) have their computer connected directly to Internet, with *maybe* a software firewall (such as the one built-in to XP). If it is possible in any way for them to connect multiple devices (laptop, PDA, phone, desktop) into their adsl/cable modem without a firewall, *THEY WILL FIND A WAY*.

A lot of the more modern Cable/DSL modems have built-in NAT/Firewalls now, which means you don't always need a Linksys (or other) NAT/Firewall device. So a goodly number of those users are no longer directly connected. And they can simply add a switch to the mix to service multiple machines.

I'd say, offhand, that I first started seeing built-in NATs in the cable modems about 2 years ago. Four to five years ago it was rare, but it seems a lot more common occurrence now.

Re:NAT is excellent and should be kept at any cost

[dbIII]

All NAT gives you is Network Adress Translation - the rest of the stuff talked about above is added extras on your combined modem/firewall/router. If you have your own subnet DHCP will still work, firewalling will still work and routing will still work even though there is no NAT at all. In a lot of cases it will even work the same way on the same device - it's just a matter of turning NAT off. The big hassle and sometimes advantage of NAT is incoming connections don't know where to go without port forwarding. However that's where a decent firewall rule setup comes in (all these devices can do it you know) and you only let stuff into your subnet that should be allowed in (the same should apply for outgoing). NAT is a hack for not having an address to route stuff to, all the other bits are the useful things.

Nope, wrong word. Cellphones, Asia, MS, USGovt

[billstewart]

SIP doesn't make much difference, because most people don't need multiple simultaneous phone calls at home (yeah, I know, people have kids.) The voice-related application that really matters is cell phones with internet connectivity - the choices are either to hide them behind a big NAT cloud, or to give them real IP addresses, and if you want to give them real IP addresses that'll probably push the remaining IPv4 address space over the cliff. Of course, the places that IP cellphones are most likely to get heavy penetration are China (where the Great Firewall means you might as well NAT) and Japan (where the mobile carriers like walled-garden services, but also like IPv6, and are willing to do 6-to-4 NAT things if they need them.)

But imagine every household in China and in cities in India and Indonesia getting broadband, whether it's DSL or cable or radio-based. (The Internet's not just for old people in Korea, after all.) Even if they've only got one address per household, that's a few hundred million IP addresses. It's easy to blow out the remaining supply of IPv4 addresses.

The US government has also mandated that its new computer and software purchases support IPv6. Unlike the 1980s, when they tried that with the OSI protocol stacks (remember GOSIP and X.400?), IPv6 is close enough to usable that agencies will gradually start adopting it, which means that vendors will also be commercializing it. So it won't be just vendors checking the box on their proposals and agencies getting waivers to ignore the stuff, at least once their Microsoft Windows PCs are supporting it widely.

Microsoft has been working on IPv6 for a while. It's available in XP if you want to dig it out of the documentation and enable it, and Vista supposedly has more support for it, not that Vista deployment is really blasting off yet. We'll see.

Of course, until there's a fair bit of usable content on the web, it'll get largely ignored by the public, but eventually it'll stagger onto the field.

Port holes

[maop]

In most Bittorent clients you can configure what ports they use. If you have admin rights on a firewall app/router then you configure that too. Network researchers have a problem with NAT because it does routing by changing and relying on certain values in upper layer protocols such as TCP and UDP. Firewalls don't necessarily do this so they are not frowned on the way NAT is.

BZZZT: Wrong answer

[Anonymous Coward]

Firewalls are there for the security and proper security requires at least two levels, perimeter and host-based, firewalls. Kernel and applications cannot be trusted alone, nor that the sole perimeter or host-based firewall will hold ie. you need both.

For a larger network it is also completely appropriate also have departmental firewalls, not just one perimeter firewall between the Internet and Intranet.

It doesn't matter wether you run IPv6, IPv4 or any other protocol, with IPSec, NAT or not you still better have depth in defence or you'll be toast one day. So it's better start early and demand at least those two levels now if you alreay havent and not wait a major havoc first.

And the needed services provided (incoming stateful-fw) should be whitelisted, anything blocking just few incoming protocols/services/sites (blacklisted), isn't worth its weight. Outgoing direction can be blacklisted and usually is, if not most secure environments where that direction is also very carefully studied and allowed only what exactly needed.

ac

ps. And, I won't even get started why DMZ is definitely needed, as is proper IPSec VPN-tunnels between the intranet-sites and it really doesn't matter
                if all that what is built is hardware or software based, the flexibility to the task in hand, viable upgrade path, performance, management and the
                reporting capabilities (not necessarily in that order) matter a lot.

Re:Nope, wrong word. Cellphones, Asia, MS, USGovt

[igb]

I'd take some convincing that IPv6 isn't precisely like GOSIP and X.400, even down to the purported enthusiasts being the US DoD and Asia. Were X.400 products usable? Yes, given some resources and effort --- I ran a production X.400(88) mailer --- but interworking was poorly tested. Although X.400 have some potential benefits that UUCP and SMTP didn't, in practice they were never deployed and the Internet community reacted quickly (MIME removed the benefits of structured bodyparts, and IMAP beat P7+ Message Stores). The rate of adoption of non-X.400 solutions was faster than the rate of adoption of the technology supposed to supplant it. And although DoD procurement had a bee in their bonnet, on the ground, the services wanted products that worked and they wanted them now.

All of this goes for IPv6. Yes, I'm sure that there's an Exchange implementation that runs on IPv6, with all the latest bits. Do you want to test it? What would the benefits be to your enterprise? Yes, I'm sure you could replace your current IPv4 backbone with one running IPv6? What benefits would it deliver to your enterprise? Yes, I'm sure there's a world of end users running IPv6 somewhere: but there's a world of people speaking Esperanto, too, just a very small one.

X.400 failed mostly because it required extra effort to deliver negative benefits: you can't talk to as many people as you can with SMTP. In what way is IPv6 different?

ian

Windows Apps = NEVER trustworthy

[Anonymous Coward]

The title says it all. Windows is the soul of spying for corporations, adware, malware, and the perversion of the very word trust that is 'Vista' the evil putrid heart of all untrustworthy malware. That micro$$$ misappropriates the very word 'trust' into its ad campaigns while perverting its meaning is akin to the media mega-monopoly industry's arrogation to itself the redefinition of the dictionary word 'pirate' to suit itself. It is an old debating society trick. The power of redefinition. If you can gain the unchallenged power to redefine the terms and words used in the very act of communication, then you have already won the debate. Money and repitition a-la-Hitler's 'Mein Kampf' has been used in each case of this. Get a good firewall program that tattles on hidden calls on the internet or other programs like Black Ice used to be, and you will see how many programs actively are stabbing you in the back. And now comes IPv6 that wants to walk around the only real defense that have, your NAT firewall be it hardware or software. Now we know who is behind IPv6! The media and malware industry in unholy alliance with micro$$$! After all, who sold the malware industry the backdoors that it coded into its micro$$ windo$ operating systems/environments in the first place and did so from its very inception. I will predict that adoption of this IPv6 will probably be done under some kind of force. The never give a sucker an even break idea.

Security is inconvenient, yes.

[jonadab]

But your other choice is to be insecure.

I mean, it's inconvenient to have to carry keys all the time, but the other alternative is to leave your house and care unlocked and, in the latter case, hotwired, so that anyone who walks up to it could just get in and drive off. (Yes, you could go with a different form of authentication besides a traditional key, but my point stands: authentication is inconvenient, but it improves security.)

NAT and firewalling create a certain amount of inconvenience, but they are well worth it for their security properties. They're not *nearly* as inconvenient as some of the other things you could do to compensate for not having them. Let's say, for instance, that you administer a network of fifty Windows desktops. You could put them all behind NAT and firewall, or you could hook them directly to the internet and individually manage all the incoming ports on each and every one of them individually. Which is more inconvenient? Or if you do neither, how much time would you have to spend recovering them from the security problems that would result? When you look at the alternatives, the firewall actually starts to sound *very* convenient.

Article is misleading

[CTachyon]

The problems that the article describes — FTP, IM file transfers, etc. — have exactly the same problems under NATless IPv4 stateful firewalls. The Internet hasn't fallen over yet, therefore the problem is overblown.

The solution in Linux has generally been application-specific kernel modules (ip_conntrack_ftp, ...) that tell the state engine (ip_conntrack) to expect related traffic. They might've finally added a user-mode interface since last time I looked, but that doesn't actually solve the problem since any user-mode program is still forced to sniff forwarded traffic for known applications.

The more elegant solution would be for each application to indicate a related connection in a way that all stateful firewalls along the route could understand. Sort of like UPnP, except UPnP only talks to a single local NAT, not every firewall along the route. However, this more elegant solution hasn't yet been invented, for IPv4 or IPv6.

Re:NAT is excellent and should be kept at any cost

[BobMcD]

You are, of course, absolutely right. The difference is that NAT provides these useful bits by default, as a matter of course. A pure Firewall Solution(tm) would most likely require someone with letters trailing their name to properly configure and deploy.

Huge difference.

Why push for such a change, unless there are more benefits than 'you only lose some of the upshots'?

Re:NAT is excellent and should be kept at any cost

[dbIII]

The difference is that NAT provides these useful bits by default, as a matter of course.

No. You are using the name of a part to describe the whole - a device with NAT comes with other stuff but that is not what NAT means. It is a slightly more technical means of falling into the same trap as those folks that call the beige box that plugs into their screen a "hard drive" which makes life difficult when talking about these things.

Re:NAT is excellent and should be kept at any cost

[BobMcD]

That's kinda my whole point right there. A NAT router does include concepts that require all sorts of letter-scrambles and RFC's to properly cite. The end user, however, simply does not care. Nor should they ever need to.

Step outside of the language-police world for just a minute and understand that a beige box without a hard drive is broken to most users. The 'hard drive' is the most important part of the box, contains all their data, and determines (via housed drivers and software) how the entirety of the rest of the box will behave. It's also the most prone to failure. Calling a PC a hard drive is incorrect if you feel that you need to control the language of the conversation to have power over it. Let go of that control, and it isn't that bad of a word to use to describe the unit. Do I need a car analogy, cause I can whip one up real quick...

A NAT device without DHCP and simple port forwarding simply betrays the purpose. NAT is meant to share an IP and an effective device will do this readily.

So to correct your comment, I am using the commonly observed effect of properly providing that part to describe the whole. Which really shouldn't be a stretch, outside of argue-on-the-internet land.

Re:NAT is excellent and should be kept at any cost

[dbIII]

Interesting rejection of the technical viewpoint there and a little unexpected on Slashdot.

We have hit the Barbarian vs Farmer argument here - where the barbarian rulers just want the farmers to provide as many goodies as they can and do not care how. When we hit the problem where it is not possible to convince someone that being correct is correct it makes it very difficult to communicate.

The O'Reilly crab book (about TCP/IP - I can not recall the title) defines things very well and is in many libraries if you do have a technical viewport.

So why is it important to not make up new and personal meanings for existing words? For example, I do not want some marketing Eloi to confuse me and say NAT is not working because they think the term is impressive (and want some of the silly converstaional "control" mentioned previously). I would prefer them to just tell me the black box that is almost entirely for other purposes is stuffed or what is indicating to them that something is wrong.

The difference between IPv6 and X.400 relevance

[billstewart]

The difference is that sometime around 2012, the IPv4 world is going to explode, fairly rudely, and you won't be able to get any more globally routable IPv4 addresses. So you'll have to do something, and the only two obvious choices are IPv6 and big chunks of NAT, which is even uglier than IPv6.

X.400 didn't have that advantage - a major entity announced that it was going to be using X.400 Real Soon Now, and you'd need to use it to be compatible with them when they got around to it, but if you really cared about that you could hack up Sendmail to translate to something your X.400 server would accept.