Hi, As more and more cool IPv6 applications and services are becoming available, I converted the former FAQ entry we had on this into a more easily found/remembered page. The page is at: http://www.sixxs.net/misc/coolstuff/ I am spamming this to NANOG, as there is bound to be ISP's out there and other service providers who might have something cool to add to that list. In case you do have some, don't hesitate to spam me back with them and I'll add them to the list so that everybody can enjoy them. As a current special, for the folks who are politically inclined, you might be interested in the G8, try: vlc http://g8tv.etherkiller.de:8000/g8-tv.ogg For a nice TV stream of the event. Greets, Jeroen
On Fri, Jun 01, 2007 at 02:28:34PM +0100, Jeroen Massar wrote:
Hi,
As more and more cool IPv6 applications and services are becoming available, I converted the former FAQ entry we had on this into a more easily found/remembered page.
I was doing some searching and came across the following slides from Gert on his operational experiences with IPv6. Not sure if others are interested, but it's worthwhile to take a few moments to look at. http://www.icann.org/meetings/lisbon/presentation-doering-ipv6-25mar07.pdf - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Jared Mauch wrote:
On Fri, Jun 01, 2007 at 02:28:34PM +0100, Jeroen Massar wrote:
Hi,
As more and more cool IPv6 applications and services are becoming available, I converted the former FAQ entry we had on this into a more easily found/remembered page.
I was doing some searching and came across the following slides from Gert on his operational experiences with IPv6. Not sure if others are interested, but it's worthwhile to take a few moments to look at.
http://www.icann.org/meetings/lisbon/presentation-doering-ipv6-25mar07.pdf
- Jared
In answer to two questions at the end of this document: • what are enterprises waiting for? • should we ditch IPv6, and live with IPv4 + NAT forever? Personally I hate NAT. But I currently work in a large enterprise environment and NAT is suprisingly popular. I came from a service provider background and some of the attitudes I've discovered towards private addresses in enterprise environments are quite surprising. Aside for the usual proponents of using NAT to hide your internal address infrastructure (which security always seem to insist upon) quite a popular design rule of from seems to be "Only carry public addresses on the public Internet and only carry private addresses on your private network" :-| If an Enterprise doesn't have a great deal for IP addresses that need to be routed on the public internet, and they thing that NAT is a _good_ design choice, it seems to me that they don't have a great deal of pressure to move to IPv6. S
On Mon, Jun 04, 2007, Sam Stickland wrote:
Personally I hate NAT. But I currently work in a large enterprise environment and NAT is suprisingly popular. I came from a service provider background and some of the attitudes I've discovered towards private addresses in enterprise environments are quite surprising. Aside for the usual proponents of using NAT to hide your internal address infrastructure (which security always seem to insist upon) quite a popular design rule of from seems to be "Only carry public addresses on the public Internet and only carry private addresses on your private network" :-|
If an Enterprise doesn't have a great deal for IP addresses that need to be routed on the public internet, and they thing that NAT is a _good_ design choice, it seems to me that they don't have a great deal of pressure to move to IPv6.
In fact, and call me crazy, but I can't help but wonder how many enterprises out there will see IPv6 and its concept of "real IPs for all machines, internal and external!" and respond with "Hell No." Anyone got any numbers for that? I'm happy to admit I don't. :) Adrian
Adrian Chadd wrote:
On Mon, Jun 04, 2007, Sam Stickland wrote:
Personally I hate NAT. But I currently work in a large enterprise environment and NAT is suprisingly popular. I came from a service provider background and some of the attitudes I've discovered towards private addresses in enterprise environments are quite surprising. Aside for the usual proponents of using NAT to hide your internal address infrastructure (which security always seem to insist upon) quite a popular design rule of from seems to be "Only carry public addresses on the public Internet and only carry private addresses on your private network" :-|
If an Enterprise doesn't have a great deal for IP addresses that need to be routed on the public internet, and they thing that NAT is a _good_ design choice, it seems to me that they don't have a great deal of pressure to move to IPv6.
In fact, and call me crazy, but I can't help but wonder how many enterprises out there will see IPv6 and its concept of "real IPs for all machines, internal and external!" and respond with "Hell No."
Anyone got any numbers for that? I'm happy to admit I don't. :)
Hence the discussion of site-local (dead), ula, ula-c etc. However widespread use of private address space in ipv4 costs people huge amounts of money when you have to merge the business processes of two or more large enterprise networks.
Adrian
In fact, and call me crazy, but I can't help but wonder how many enterprises out there will see IPv6 and its concept of "real IPs for all machines, internal and external!" and respond with "Hell No."
That's an education problem. There's no security gain from not having real IPs on machines. Any belief that there is results from a lack of understanding.
Anyone got any numbers for that? I'm happy to admit I don't. :)
Nope.
Hence the discussion of site-local (dead), ula, ula-c etc.
Site-Local sort of provided that, but, as pointed out, dead. ULA-random sort of provides it, except that ULA-random only provides likely uniqueness and so really is the worst of both problems. There's not enough guarantee of collision to really prevent it from getting routed, and, there's not enough of a guarantee of uniqueness to make organizations worried about such things comfortable with it. ULA-C is just Provider-Independent Real addresses with a label stuck on them that says "These aren't the droids you're looking for, move along". Really, the only thing that distinguishes ULA-C from PI is mindset and router configuration. The former is known to vary in unpredictable manners. The latter is known to vary with the application of $$$.
However widespread use of private address space in ipv4 costs people huge amounts of money when you have to merge the business processes of two or more large enterprise networks.
Yep. Hence the v6 concept of real addresses everywhere. People seem to have forgotten that private addresses and NAT were a hack designed to cope with a situation that v6 is supposed to actually solve. I admit v6 does not completely solve the problem (at least not yet), but, it solves enough of it that we shouldn't be clinging to the v4 hacks that got us by as we move to v6. Owen
Owen DeLong <owen@delong.com> writes:
There's no security gain from not having real IPs on machines. Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people are liable to start believing it's true :-). *No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site? Shall I do the experiment again where I set up a Linux box at an RFC1918 address, behind a NAT device, publish the root password of the Linux box and its RFC1918 address, and invite all comers to prove me wrong by showing evidence that they've successfully logged into the Linux box? When I last did this, I got a handful of emails, some quite snide, suggesting I was some combination of ignorant, stupid, and reckless; the Linux box for some reason remained unmolested. Jim Shankland
On 4-Jun-2007, at 14:32, Jim Shankland wrote:
Shall I do the experiment again where I set up a Linux box at an RFC1918 address, behind a NAT device, publish the root password of the Linux box and its RFC1918 address, and invite all comers to prove me wrong by showing evidence that they've successfully logged into the Linux box?
Perhaps you should run a corresponding experiment whereby you set up a linux box with a globally-unique address, put it behind a firewall which blocks all incoming traffic to that box, and issue a similar invitation. Do you think the results will be different? Joe
Joe Abley wrote:
On 4-Jun-2007, at 14:32, Jim Shankland wrote:
Shall I do the experiment again where I set up a Linux box at an RFC1918 address, behind a NAT device, publish the root password of the Linux box and its RFC1918 address, and invite all comers to prove me wrong by showing evidence that they've successfully logged into the Linux box?
Perhaps you should run a corresponding experiment whereby you set up a linux box with a globally-unique address, put it behind a firewall which blocks all incoming traffic to that box, and issue a similar invitation.
Do you think the results will be different?
I fear a somewhat more cynical person could interpret the results of such an experiment to mean that NAT is as good as a firewall ;) S
I'm sure everyone understands the underlying principle, but I'm constantly making the point that even the best firewall is not a total security solution. Forget antivirus, IDS, host authentication, etc., and just look on the perimeter. At least four device types lead inside from the DMZ: NAT Firewalls of various flavors VPN concentrators/security gateways Rate-limiting anti-DOS devices to protect host-to-host encryption For small and medium enterprises, these functions might, as an implementation choice, reside in the same box; NAT is most likely to coexist with firewalling or VPN concentration. The latter gets a little Zen-ish if the VPN concentrator acts as a separately addressed proxy anyway. -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Sam Stickland Sent: Monday, June 04, 2007 3:04 PM To: Joe Abley Cc: Jim Shankland; Owen DeLong; NANOG list Subject: Re: Security gain from NAT Joe Abley wrote:
On 4-Jun-2007, at 14:32, Jim Shankland wrote:
Shall I do the experiment again where I set up a Linux box at an RFC1918 address, behind a NAT device, publish the root password of the Linux box and its RFC1918 address, and invite all comers to prove me wrong by showing evidence that they've successfully logged into the Linux box?
Perhaps you should run a corresponding experiment whereby you set up a linux box with a globally-unique address, put it behind a firewall which blocks all incoming traffic to that box, and issue a similar invitation.
Do you think the results will be different?
I fear a somewhat more cynical person could interpret the results of such an experiment to mean that NAT is as good as a firewall ;) S
On Jun 4, 2007, at 11:32 AM, Jim Shankland wrote:
Owen DeLong <owen@delong.com> writes:
There's no security gain from not having real IPs on machines. Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people are liable to start believing it's true :-).
Maybe because it _IS_ true.
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Correct. There's nothing you get from NAT in that respect that you do not get from good stateful inspection firewalls. NONE whatsoever.
Shall I do the experiment again where I set up a Linux box at an RFC1918 address, behind a NAT device, publish the root password of the Linux box and its RFC1918 address, and invite all comers to prove me wrong by showing evidence that they've successfully logged into the Linux box? When I last did this, I got a handful of emails, some quite snide, suggesting I was some combination of ignorant, stupid, and reckless; the Linux box for some reason remained unmolested.
That doesn't prove that NAT had anything to do with the security. NAT implies stateful inspection. I could conduct the exact same experiment with a Linux box behind a stateful inspection firewall with legitimate addresses and achieve the exact same result. NAT did nothing for you. Stateful inspection is where you got your security. I'm so tired of people who fail to understand that NAT has nothing to do with security, because they forget that stateful inspection is required in order to make NAT work. However, NAT is not required for stateful inspection to work. Owen
On Mon, Jun 04, 2007 at 11:47:15AM -0700, Owen DeLong wrote:
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Correct. There's nothing you get from NAT in that respect that you do not get from good stateful inspection firewalls. NONE whatsoever.
Argueably the instant hit of IP source anononymity you get with NAT is a security benefit (from the point of view of the user). Of course these days there all sorts of fragment and timing analyses that will allow you to determine origin commonality behind NAT, but it's nowhere near as convenient as a public IP address. A non-NAT stateful firewall can't simulate that, you need high-rotation dhcp or similar to get close. Although IPv6 privacy addresses rock :-) The argument can go either way, you can spin it as a benefit for the network operator ("wow, user activity and problems are now more readily identifiable and trackable") or you can see it as an organisational privacy issue ("crap, now macrumors can tell that the CEO follows them obsessively"). NAT is still evil though, the problems it causes operationally are just plain not worth it. -- Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
On Mon, Jun 04, 2007 at 08:12:45PM +0100, Colm MacCarthaigh wrote:
The argument can go either way, you can spin it as a benefit for the network operator ("wow, user activity and problems are now more readily identifiable and trackable") or you can see it as an organisational privacy issue ("crap, now macrumors can tell that the CEO follows them obsessively").
Surely that second quote should be "crap, now macrumors can tell that one person in our office follows them obsessively"? Unless there's publically-available information that indicates that IP address is your CEO's (which is a whole other topic -- publically available rDNS for company-internal IPv6 ranges). Talking about HTTP traffic in particular, though, it's pretty likely that macrumors already knows that they've only got one person in your office following them obsessively already, using cookies. It's a rare CEO that knows to block most cookies (and clear out their cookie jar regularly).
NAT is still evil though, the problems it causes operationally are just plain not worth it.
Amen to that. - Matt -- I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. -- Bjarne Stroustrup
Surely that second quote should be "crap, now macrumors can tell that one person in our office follows them obsessively"? Unless there's publically-available information that indicates that IP address is your CEO's (which is a whole other topic -- publically available rDNS for company-internal IPv6 ranges). In addition, IPv6 supports temporary addresses that can change every day. If your browser binds to a temporary address, and it changes daily, then
the anonymizing feature of NAT becomes a whole lot less useful.
NAT is still evil though, the problems it causes operationally are just plain not worth it. Amen to that. I think evil sums up NAT nicely :)
-Don
I figured SMB would chime in...but his research says it's not so anonymous. http://illuminati.coralcdn.org/docs/bellovin.fnat.pdf jas Colm MacCarthaigh wrote:
On Mon, Jun 04, 2007 at 11:47:15AM -0700, Owen DeLong wrote:
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Correct. There's nothing you get from NAT in that respect that you do not get from good stateful inspection firewalls. NONE whatsoever.
Argueably the instant hit of IP source anononymity you get with NAT is a security benefit (from the point of view of the user). Of course these days there all sorts of fragment and timing analyses that will allow you to determine origin commonality behind NAT, but it's nowhere near as convenient as a public IP address.
A non-NAT stateful firewall can't simulate that, you need high-rotation dhcp or similar to get close. Although IPv6 privacy addresses rock :-)
The argument can go either way, you can spin it as a benefit for the network operator ("wow, user activity and problems are now more readily identifiable and trackable") or you can see it as an organisational privacy issue ("crap, now macrumors can tell that the CEO follows them obsessively").
NAT is still evil though, the problems it causes operationally are just plain not worth it.
At 09:07 PM 6/4/2007, Jason Lewis wrote:
I figured SMB would chime in...but his research says it's not so anonymous.
Give or take NAT boxes / firewalls that specifically have features to mess with the IP ID. The SonicWALL products have, for example, a checkbox that says: "Randomize IP ID". Some vendors apparently have taken measures to ensure methods such as monitoring IP ID are less effective. The paper notes this, and the issues with doing this. So the "not so anonymous" statement above is really "not so anonymous, give or take the implementation of the firewall/NAT".
On Mon, 04 Jun 2007 22:06:25 -0400 Daniel Senie <dts@senie.com> wrote:
At 09:07 PM 6/4/2007, Jason Lewis wrote:
I figured SMB would chime in...but his research says it's not so anonymous.
The traffic load on this list is rather high; I've had to flush most of this and other threads....
Give or take NAT boxes / firewalls that specifically have features to mess with the IP ID. The SonicWALL products have, for example, a checkbox that says: "Randomize IP ID".
That's relatively new, and possibly in response to my paper; as of when I wrote it, I couldn't find any vendors that DTRT.
Some vendors apparently have taken measures to ensure methods such as monitoring IP ID are less effective. The paper notes this, and the issues with doing this.
So the "not so anonymous" statement above is really "not so anonymous, give or take the implementation of the firewall/NAT".
I suspect there are other information leaks, such as the RFC 1323 timestamps, TCP sequence numbers (for some platforms), port number allocation, etc. Many of these are (or can be) randomized on some platforms, but I don't know of any systematic analysis. I also wonder if some popular web sites' cookies embed the IP address -- possibly encrypted to them, so they can track where you are. I'm 100% that some sites do that for authenticated connections. (On the larger issue, I feel that typical NATs provide no security benefit over typical stateful packet filters. Given other issues -- traceability of attacks, impediments to end-to-end secure connections, the need for special-purpose things like STUN servers, etc. -- I could make a good case that they're a net disadvantage. But I'm on the verge of flushing this thread, so I may not see the responses....) --Steve Bellovin, http://www.cs.columbia.edu/~smb
On Jun 4, 2007, at 11:32 AM, Jim Shankland wrote:
Owen DeLong <owen@delong.com> writes:
There's no security gain from not having real IPs on machines. Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people are liable to start believing it's true :-).
Maybe because it _IS_ true.
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Correct. There's nothing you get from NAT in that respect that you do not get from good stateful inspection firewalls. NONE whatsoever.
Sorry, Owen, but your argument is ridiculous. The original statement was "[t]here's no security gain from not having real IPs on machines". If someone said, "there's no security gain from locking your doors", would you refute it by arguing that there's no security gain from locking your doors that you don't get from posting armed guards round the clock? DS
Sorry, Owen, but your argument is ridiculous. The original statement was "[t]here's no security gain from not having real IPs on machines". If someone said, "there's no security gain from locking your doors", would you refute it by arguing that there's no security gain from locking your doors that you don't get from posting armed guards round the clock? You're argument is equally ridiculous because in order to work the NAT box has to do stateful inspection anyway!
A better statement would be: "there's no security gain from locking your doors" (NAT), if you have already posted "armed guards round the clock" (Stateful Inspection) NAT provides protection in the case where you have a stateful inspection firewall that fails open- something that no serious firewall I have ever seen does. If they aren't doing stateful inspection- then they aren't routing at all (or certainly shouldn't be). -Don
On Jun 4, 2007, at 1:41 PM, David Schwartz wrote:
On Jun 4, 2007, at 11:32 AM, Jim Shankland wrote:
Owen DeLong <owen@delong.com> writes:
There's no security gain from not having real IPs on machines. Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people are liable to start believing it's true :-).
Maybe because it _IS_ true.
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Correct. There's nothing you get from NAT in that respect that you do not get from good stateful inspection firewalls. NONE whatsoever.
Sorry, Owen, but your argument is ridiculous. The original statement was "[t]here's no security gain from not having real IPs on machines". If someone said, "there's no security gain from locking your doors", would you refute it by arguing that there's no security gain from locking your doors that you don't get from posting armed guards round the clock?
Except that's not the argument. The argument would map better to: There's no security gain from having a screen door in front of your door with a lock and dead-bolt on it that you don't get from a door with a lock and dead-bolt on it. I posit that a screen door does not provide any security. A lock and deadbolt provide some security. NAT/PAT is a screen door. Not having public addresses is a screen door. A stateful inspection firewall is a lock and deadbolt. Owen
I posit that a screen door does not provide any security. A lock and deadbolt provide some security. NAT/PAT is a screen door. Not having public addresses is a screen door. A stateful inspection firewall is a lock and deadbolt.
This is a fine piece of rhetoric, but it's manifestly false and seriously misleading. I have a cluster of Windows machines at my store with no networking security at all. They're behind NAT/PAT and nothing else. None of them have ever been broken into. For a screen door, that's a mighty impressive screen door. I can give you the root password to a Linux machine running telnetd and sshd. If it's behind NAT/PAT, you will not get into it. Period. I can give you the administrator password to a Windows machine with file sharing wide open. If it's behind NAT/PAT, you will not get into it. Period. The only ways into these machines would be if the NAT/PAT device were misconfigured, another machine on the secure network were compromised, or another gateway into the secure network was set up. Guess what? All of these things would defeat a stateful inspection firewall as well. Are there things most stateful inspection firewalls can do that NAT/PAT does not do? Definitely. Are those things valuable and in some cases vital? Definitely. So why lie and distory what NAT/PAT actually does do? A large class of security vulnerabilities require the attacker to reach out to the machine first, and NAT/PAT stops those attacks completely. Is that enough if there are other attacks that it does nothing to stop? Clearly not. Does that change the fact that it actually does completely prevent a large class of serious attacks? No, it does not. Is a car alarm useless because some professtional theives can disable it? Is a lock useless because some thieves can pick it? Many exploits only go after low-hanging fruit, and NAT/PAT stops them. DS
On Mon, Jun 04, 2007 at 04:27:14PM -0700, David Schwartz wrote:
I posit that a screen door does not provide any security. A lock and deadbolt provide some security. NAT/PAT is a screen door. Not having public addresses is a screen door. A stateful inspection firewall is a lock and deadbolt.
This is a fine piece of rhetoric, but it's manifestly false and seriously misleading.
I have a cluster of Windows machines at my store with no networking security at all. They're behind NAT/PAT and nothing else.
Can you give us technical details about how you're doing NAT/PAT without any form of stateful packet inspection? I'm sure we'd all be most interested. If it turns out that you are, in fact, using stateful inspection, then you've got that lock and deadbolt installed, but haven't noticed it behind the screen door.
I can give you the root password to a Linux machine running telnetd and sshd. If it's behind NAT/PAT, you will not get into it. Period.
I can give you the administrator password to a Windows machine with file sharing wide open. If it's behind NAT/PAT, you will not get into it. Period.
The only ways into these machines would be if the NAT/PAT device were misconfigured, another machine on the secure network were compromised, or another gateway into the secure network was set up. Guess what? All of these things would defeat a stateful inspection firewall as well.
Which means that -- tada! -- NAT/PAT isn't giving you anything that the stateful inspection firewall isn't.
Are there things most stateful inspection firewalls can do that NAT/PAT does not do? Definitely. Are those things valuable and in some cases vital? Definitely. So why lie and distory what NAT/PAT actually does do? A large class of security vulnerabilities require the attacker to reach out to the machine first, and NAT/PAT stops those attacks completely.
As does stateful inspection. Duck season! - Matt -- when SuSE are doing better than you at publishing the tools they use, it's a hint that maybe you suck. -- Andrew Suffield, debian-devel
Combined responses to save bandwidth and hassle (and number of times you have to press 'd'): --
Just because it's behind NAT, does not mean it's unreahcable from the internet:
Okay, so exactly how many times do you think we have to say in this thread that by "NAT/PAT", we mean NAT/PAT as typically implemented in the very cheapest routers in their default configuration? --
I can do the same without NAT/PAT. Period. The benefits are from "disallow new inbound by default", *not* address muxing.
That you can do something without NAT/PAT tells you nothing about what NAT/PAT does. Why state an uncontested unrelated point nobody disagrees with when there is an actual live disagreement about what security NAT/PAT does or doesn't provide? (Hint: NAT/PAT, as discussed here, includes "disallow new inbound by default"). --
Can you give us technical details about how you're doing NAT/PAT without any form of stateful packet inspection? I'm sure we'd all be most interested.
If it turns out that you are, in fact, using stateful inspection, then you've got that lock and deadbolt installed, but haven't noticed it behind the screen door.
Ahh, right. You can't use a car to get to work, you need a frame, an engine, an electrical system, and a starter. So that means cars aren't means of transportion.
Which means that -- tada! -- NAT/PAT isn't giving you anything that the stateful inspection firewall isn't.
That's wonderful, but that's not even remotely respondive to what I'm saying. I'm responding to Owen's claim that NAT/PAT doesn't provide any security, not that it doesn't provide you any security that a stateful inspection firewall doesn't or can't.
Are there things most stateful inspection firewalls can do that NAT/PAT does not do? Definitely. Are those things valuable and in some cases vital? Definitely. So why lie and distory what NAT/PAT actually does do? A large class of security vulnerabilities require the attacker to reach out to the machine first, and NAT/PAT stops those attacks completely.
As does stateful inspection.
Wonderful, but when there's an actual live disagreement, injecting an unrelated point that nobody disagrees with isn't helpful. The issue is whether or not NAT/PAT provides any security. If stateful inspection is a necessary part of NAT/PAT, and stateful inspection provides some security, the NAT/PAT provides some security. This is so for the same reason a car provides all the benefits of an engine, a fuel tank, a seat belt, and so on. You cannot establish that a car provides no transportation features by showing that it provides no transportation features not provided by an engine, a gas tank, a transmission, and so on. Things are the sum of their parts. --
In order to make (dynamic) NAT work you need to implement SI- that's what protects you. What does NAT get you above and beyond the SI you have already imeplmented?
What does a car get you above and beyond the engine, transmission, starter, and so on? It gets you all those things in one convenient package that you just buy, start, and drive. NAT provides all the advantages its component parts provide. Really. --
Not true. In order to be behind PAT, they are behind stateful inspection. You cannot have PAT without stateful inspection. It simply cannot work. However, you _CAN_ have stateful inspection without PAT and it provides every bit as much security as it does with PAT.
1) You cannot have PAT without stateful inspection, that is, stateful inspection is a part of the PAT implementations we are talking about here. 2) Stateful inspection provides security benefits. Therefore, PAT provides security benefits.
Given the data from my previous message and the fact that you are calling NAT what is really NAT/PAT+SI, do you now realize that the SI portion of NAT/PAT+SI is what provides the security, or, do you still have the mistaken impression that NAT/PAT somehow contributes to security?
This is absolute complete nonsense. Are you next going to claim that what I call a car is actually car/engine and that since it's the engine that provides the motion, cars don't provide motion? --
No one is saying they won't. What people are arguing is that NAT doesn't get you anything more than a stateful inspection firewall while at the same time breaking a whole lot of other things and introducing unnecessary complexity.
Yes, people are saying they won't. For example, Owen said: "I posit that a screen door does not provide any security. A lock and deadbolt provide some security. NAT/PAT is a screen door. Not having public addresses is a screen door. A stateful inspection firewall is a lock and deadbolt." What part of this analogy is comparable with NAT always including all the benefits of SI? You think Owen was really trying to say that NAT/PAT is a screen door that always includes a lock and deadbolt that somehow makes the screen door keep intruders out?! Owen was, if not saying, definitely implying that a NAT/PAT implementation provided the security of a screen door and that SI provided a lock and deadbolt, that is, that a NAT/PAT implementation would not be as secure as an SI firewall. This is wholly incompatible with his new claim that NAT/PAT always includes SI and therefore an actual NAT/PAT device must always provide the security of SI. DS
David Schwartz wrote:
Just because it's behind NAT, does not mean it's unreahcable from the internet:
Okay, so exactly how many times do you think we have to say in this thread that by "NAT/PAT", we mean NAT/PAT as typically implemented in the very cheapest routers in their default configuration?
And my $50 Linksys has a "DMZ host" configuration item, as well as configurable port range forwarding entries. 1: "Gee, I want to run this p2p app, and it doesn't work." 2: "Go to http://192.168.1.1 and enter 192.168.1.100 into the DMZ Host" 1: "Great, it works now!"
I can do the same without NAT/PAT. Period. The benefits are from "disallow new inbound by default", *not* address muxing.
That you can do something without NAT/PAT tells you nothing about what NAT/PAT does. Why state an uncontested unrelated point nobody disagrees with when there is an actual live disagreement about what security NAT/PAT does or doesn't provide? (Hint: NAT/PAT, as discussed here, includes "disallow new inbound by default").
Because it was stated the NAT/PAT provides security, and it doesn't. The DMZ host above is still NAT'ed (and the configurable port forwarding ranges are still PAT'ed), but the security "provided by NAT" just went out the window.
Which means that -- tada! -- NAT/PAT isn't giving you anything that the stateful inspection firewall isn't.
That's wonderful, but that's not even remotely respondive to what I'm saying. I'm responding to Owen's claim that NAT/PAT doesn't provide any security, not that it doesn't provide you any security that a stateful inspection firewall doesn't or can't.
But it is correct. Just mangling the addresses in the headers doesn't actually stop anything from getting through, it just means it gets through mangled. The security comes from SI and dropping packets that don't have an active session established from inside, or related.
In order to make (dynamic) NAT work you need to implement SI- that's what protects you. What does NAT get you above and beyond the SI you have already imeplmented?
What does a car get you above and beyond the engine, transmission, starter, and so on? It gets you all those things in one convenient package that you just buy, start, and drive. NAT provides all the advantages its component parts provide. Really.
And in IPv6-land, it will be trivial to build consumer level IPv6 firewalls that has a default of dropping everything inbound, which is what the SI of a dynamic NAT gives you. Exactly the same level of security and a whole lot less breakage. -- Jeff McAdams "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin
On 6/5/07, David Schwartz <davids@webmaster.com> wrote:
Combined responses to save bandwidth and hassle (and number of times you have to press 'd'):
--
Just because it's behind NAT, does not mean it's unreahcable from the internet:
Okay, so exactly how many times do you think we have to say in this thread that by "NAT/PAT", we mean NAT/PAT as typically implemented in the very cheapest routers in their default configuration?
Even the cheapest routers have a 'DMZ' configuration option that adds a rule that, by default, sends all the traffic to a particular host. And using that is a fairly common solution to bypassing problems with port forwarding and NAT.
On 6/4/07, David Schwartz <davids@webmaster.com> wrote:
I can give you the root password to a Linux machine running telnetd and sshd. If it's behind NAT/PAT, you will not get into it. Period.
Just because it's behind NAT, does not mean it's unreahcable from the internet: Fenrir:~% telnet ipv4.nonexiste.net [1028] 19:57:17 Trying 68.90.179.13... Connected to ipv4.nonexiste.net. Escape character is '^]'. Password: Last login: Sat Jun 2 14:26:58 2007 from inuyasha.nonexiste.net on pts/0 Linux nira 2.6.18-1-486 #1 Sat Oct 21 16:34:06 UTC 2006 i686 GNU/Linux You have mail. Last was Mon 04 Jun 2007 06:57:37 PM CDT on pts/8. nira:~$ /sbin/ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:20:78:03:F6:B0 inet addr:172.16.16.8 Bcast:172.16.16.255 Mask:255.255.255.0 And no, that's not misconfigured.
I can give you the root password to a Linux machine running telnetd and sshd. If it's behind NAT/PAT, you will not get into it. Period. I'll give you root password to a half a dozen directly connected Linux boxes and you still won't be able to get in.
I can give you the administrator password to a Windows machine with file sharing wide open. If it's behind NAT/PAT, you will not get into it. Period. The beauty of IPv6 is that Windows can, by default, bind to the Link Local address for file sharing and you still won't be able to get into it but your local network will still work.
The only ways into these machines would be if the NAT/PAT device were misconfigured, another machine on the secure network were compromised, or another gateway into the secure network was set up. Guess what? All of these things would defeat a stateful inspection firewall as well. No one is saying they won't. What people are arguing is that NAT doesn't get you anything more than a stateful inspection firewall while at the same time breaking a whole lot of other things and introducing unnecessary complexity.
Definitely. So why lie and distory what NAT/PAT actually does do? A large class of security vulnerabilities require the attacker to reach out to the machine first, and NAT/PAT stops those attacks completely. The point is simply that SI does this without the complexity and inanity that is NAT. If you want to deal with it- go right ahead. But the original argument (since we seem to have forgotten) is simply that NAT doesn't get you anything that SI doesn't already provide- while at the same time making everything a lot more complex.
Is a car alarm useless because some professtional theives can disable it? Is a lock useless because some thieves can pick it? Many exploits only go after low-hanging fruit, and NAT/PAT stops them. For the nth time- so does SI- and it does it without the header mangling, complexity and troubleshooting headaches that come with NAT.
No one is denying that NAT works- but it works well because of SI, not because of NAT (in fact static NAT does nothing to stop an attack in any way shape or form). The question we are asking you is what does NAT get us over and above SI? Because if the answer is nothing- then not having to deal with NAT's shortcomings is reason enough to ditch it in favor of straight forward SI. -Don
DS> Date: Mon, 4 Jun 2007 16:27:14 -0700 DS> From: David Schwartz [ snipped throughout ] DS> I can give you the root password to a Linux machine running telnetd DS> and sshd. If it's behind NAT/PAT, you will not get into it. Period. DS> DS> I can give you the administrator password to a Windows machine with DS> file sharing wide open. If it's behind NAT/PAT, you will not get DS> into it. Period. I can do the same without NAT/PAT. Period. The benefits are from "disallow new inbound by default", *not* address muxing. N + S = true !N + S = true N + !S = invalid state (can't happen) !N + !S = false Note carefully how one can simplify the truth table to S = true !S = invalid / false A "true" outcome depends on the presence of "S". It is independent of "N". DS> The only ways into these machines would be if the NAT/PAT device DS> were misconfigured, another machine on the secure network were DS> compromised, or another gateway into the secure network was set up. DS> Guess what? All of these things would defeat a stateful inspection DS> firewall as well. Red herring and straw man. The argument is: "Does NAT/PAT address- hiding provide special benefit due to the fact that IP addresses are being muxed?" See above truth table. DS> A large class of security vulnerabilities require the attacker to DS> reach out to the machine first, and NAT/PAT stops those attacks DS> completely. No. Stateful filtering stops those attacks completely. NAT/PAT works merely by its automatic inclusion of stateful filtering, and _ipso facto_ does nothing. See above truth table. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
The only ways into these machines would be if the NAT/PAT device were misconfigured, another machine on the secure network were compromised, or another gateway into the secure network was set up. Guess what? All of these things would defeat a stateful inspection firewall as well.
I disagree. (All of the below is hypothetical, I haven't tested it, but I believe it to be true.) Premise 1: The machines behind the firewall are actually on and functioning, and presumably may be even being used. Premise 2: The OS's on the machines will periodically do *some* kind of traffic. Some common examples might be ntp syncronisation, or DNS resolving of an update service for antivirus, OS patches, whatever. The traffic may be provided by the user actually using the machine for whatever real users actually do. Premise 3: Many NAPT's are of the "Cone" type. This is desirable for end users as it allows their applications/devices to use their NAPT busting technologys (STUN, Teredo etc) without having to configure static port forwards. Premise 4: The external port chosen for an outgoing protocol is easily guessed. Many NAPT boxes will prefer to use the same port as the original host, or will assign port mappings sequentially a bit of research here would go a long way, presumably entire networks are likely to be using the same NAPT's in an ISP's provided CPE. Thus, for example if you are running a single host behind a NAPT box that is doing regular NTP queries and I can guess the external port on the NAPT box which with a bit of research I suspect is trivial, I can send that port on your external IP a packet and it will be forwarded back to your machine. This could easily lead to a compromise via a buffer overflow or other exploit. This would primarily work for UDP based services that by design tend to be used over the Internet itself such as DNS, NTP, SIP etc. It seems unlikely that this would work against TCP based services. Exploits in ICMP could also be "tunneled" back through a NAPT box in a similar manner. GRE/IPIP/IPv6/ESP/AH can probably use similar techniques to infect machines behind a NAPT box (Disclaimer I don't know those protocols very well, but on the flipside, I suspect that NAPT boxes don't know them very well either and do dumb things with them like forward all GRE packets to the one host inside your network that has ever spoken GRE). Just because you've never seen someone exploit through a NAPT box doesn't mean it won't happen.
On 6/4/07, David Schwartz <davids@webmaster.com> wrote:
I posit that a screen door does not provide any security. A lock and deadbolt provide some security. NAT/PAT is a screen door. This is a fine piece of rhetoric, but it's manifestly false and seriously misleading.
Hi, David I think the essence of what prior post is suggesting is that NAT itself is not necessarily a security feature, but there is a popular method of using NAT to get a feature that comes with it and has security benefits, that really goes by the name SPI, and which can be decoupled from what it means to have a "NAT", and that feature can and should perhaps be implemented alone, on its own right, instead of NAT. In other words "In IPv4 we got a security gain that happened to be packaged with NAT," but in ipv6 we have another way of getting almost the very same gains, except without the disadvantages of NAT. It should be cheaper to implement SPI than full blown NAT capabilities. However, that greatly depends on what consumers (end users) will demand, and a handful of hardware manufacturers will provide, if/when some inexpensive gateway type hardware becomes available for end users that has IPv6 support. If IPv6 allows them to "not buy the NAT" box, then the typical end user won't necessarily instead buy a SPI box, they may buy no box at all, other than say, a $10 switch or hub, or it might be on the same box as their access equipment, it will be less expensive. Therefore they might have fewer protections in the real world, unless upstream provider's routing equipment provides them with SPI: that's not very likely. NAT-less SPI may strangely have a higher price tag than NAT+SPI. A hardware vendor selling an IPv4 SPI box might typically have labelled that product as a security appliance, making it cost more, because "SPI/security/firewall" was considered an "enterprise feature", NAT was considered a commodity functionality. For SPI without translation to replace NAT, it needs to become a commodity functionality that every end user IPv6 gateway supports and has enabled by default, setup with no holes (i.e. ports open) by default, out of the box. It is understandable that end users rely on the cheapest boxes they can get, that best suited their immediate needs -- it was convenient for the equipment to have secure defaults; I would hope that hardware makers would continue to provide security by default with IPv6, since all too many OSes have insecure defaults. Should users want it badly enough, nothing forces hardware makers to stick with the best known solutions -- HW makers may specify NAT or other hacks all on their own... if the transport protocol standards don't specify it. I think some hardware maker is probably going to just invent and patent IPv6 NAT, since noone thought to specify it, and implement in their products just to list "[brand name] IP Version 6 private addressing" in their marketing materials, for said premium device(s). Today's IPv4 NAT box may well be the next decade's SOCKS6 proxy box, even if there is no technical need whatsoever for it; there is a comfort factor here, since some users of IPv4 have become accustomed to certain hacks, and they will not be forgotten easily. IPv6 users may not like that in case an internal machine is compromised to some extent, , without NAT, the actual ip addresses of other machines behind the gateway may have become known in advance of the initial compromise, but if the addresses were private, extra effort would normally be required to discover what exactly the private addresses were, only possible after the compromise, while the timer is ticking for the incursion to be discovered.
I can give you the root password to a Linux machine running telnetd and sshd. If it's behind NAT/PAT, you will not get into it. Period.
That might be so, but the assurance may not be 100%. In practice, your NAT box, even if properly configured may well have a number of different types of holes, and it may be possible for an outsider to open a session you didn't anticipate. I would suggest that implementations of NAT and SPI suffer the same type of deficiencies in that respect.
Are there things most stateful inspection firewalls can do that NAT/PAT does not do? Definitely. Are those things valuable and in some cases vital? Definitely. So why lie and distory what NAT/PAT actually does do? A large class of security vulnerabilities require the attacker to reach out to the machine first, and NAT/PAT stops those attacks completely.
If there's something remaining a NAT is good for, that doesn't have a much better replacement technology, or hasn't been mentioned yet anywhere, then it should be spelled out, to the ipv6 wg, so it can be ascertained... whether a NAT is still necessary to offer that advantage, or whether NAT is merely the box that capability happened to come in for IPv4.
Is a car alarm useless because some professtional theives can disable it? Is a lock useless because some thieves can pick it? Many exploits only go after low-hanging fruit, and NAT/PAT stops them.
No, but a lock should eventually be replaced if it doesn't entirely lock and has extra features that cause problems and don't really contribute to the task of locking, but make the lock more complicated, and possibly easier to defeat, when a cheaper, better lock can be made in its place. No need to make old-style easy-pick locks that take skeleton keys anymore, no need to even specify them. Ideally individual NICs would be smart enough for SPI to be done on host NICs. Spreading the load, and sharing a "connections table" with the host OS rather than imposing load down upon one NAT box (to manage the connections tables for many interfaces), or requiring "timing out" to know when a connection is still possibly active or not. I.E. It's possibly a little bit better to have a deadbolt on each of your doors, instead of having only one big fence around your neighborhood, with just one lock on that gate, no locks on your individual doors, and all neighbors sharing a single mailing address. There is a chance that someone you don't know can still get mail to you. Also, one of your neighbors could turn out to be the bad guy (one of your other systems could become infected by some trojan, perhaps it is a laptop and was temporarily plugged into a different network, and compromised at that time) There is a security gain involved if you have NAT, over having nothing at all, but there are other security measures that can possibly be taken that obsolete some major NAT security gains... -- -J
I posit that a screen door does not provide any security.
"Any" is too strong a word. For people living in an area with malaria-carrying mosquitoes, that screen door may be more important for security than a solid steel door with a deadbolt. It all depends on what the risks are, what you are protecting, and where your priorities are. It is rather odd to see this discussion just a few weeks after the IETF issued RFC 4864 to address just this misconception of NAT. How many of the participants have read the RFC? Assuming vendors of cheap consumer IPv6 gateway boxes implement all the LNP (Local Network Protection) features of RFC 4864, is there any reason for these boxes to also support NAT? As far as I can see the only good reason to put NAT in an IPv6 gateway is because uneducated consumers demand it as a checklist feature. In that case, let's hope that it is off by default and that disabling the NAT does not disrupt any of the other LNP features. That way, when the customer calls the support desk to complain that they are not getting SIP calls from Mom, you can tell them to turn off the NAT and try again. --Michael Dillon
On 5/06/2007, at 9:29 PM, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
I posit that a screen door does not provide any security.
"Any" is too strong a word. For people living in an area with malaria-carrying mosquitoes, that screen door may be more important for security than a solid steel door with a deadbolt. It all depends on what the risks are, what you are protecting, and where your priorities are.
It is rather odd to see this discussion just a few weeks after the IETF issued RFC 4864 to address just this misconception of NAT. How many of the participants have read the RFC? Assuming vendors of cheap consumer IPv6 gateway boxes implement all the LNP (Local Network Protection) features of RFC 4864, is there any reason for these boxes to also support NAT?
As far as I can see the only good reason to put NAT in an IPv6 gateway is because uneducated consumers demand it as a checklist feature. In that case, let's hope that it is off by default and that disabling the NAT does not disrupt any of the other LNP features. That way, when the customer calls the support desk to complain that they are not getting SIP calls from Mom, you can tell them to turn off the NAT and try again.
Precisely. I don't think anyone is suggesting that you should put NAPT in an IPv6 gateway. A few days ago it was suggested by Sam Stickland that a blocker to moving to IPv6 was the lack of NAPT, and the security features that are an integral part of it's functionality. The comment was then made (I think by Owen DeLong, although he implied it instead of stating it clearly) that stateful inspection can be done independently of NAPT, and that the anonymity can be provided by the privacy extensions was mentioned by both myself and someone else. Noone has disputed either of those two points so far. The counterpoint seems to be that you get stateful inspection with NAPT, which isn't really disputed, as it's obvious. It seems that that's been misinterpreted as people suggesting that instead of IPv6 and SI+Privacy, we go with IPv6 and NAPT, and to that people are saying "Just use SI". I'm unclear as to why this is still being discussed to be honest, as noone is claiming that NAPT provides additional security over SI +Privacy, which was presented as a solution to the original concern. The rest seems to just be trying to pick holes in misinterpretations of each others posts, which doesn't really go anywhere, let alone make sense. As I see it, the next step for everyone here is educating people that NAPT-equivalent security can be provided in other ways. Let's focus our energies on that, instead of pointless debate. So, when talking to your CPE vendor about IPv6, make SI a requirement, and encourage end users to turn on Privacy extensions for address selection. It shouldn't be a hard sell at all - the only consumer grade routers that I'm aware of that do IPv6 are the Cisco 8xx, and the Apple Airport Extreme (n). Both do SI, the Airport does it by default (now). -- Nathan Ward
Nathan Ward wrote:
On 5/06/2007, at 9:29 PM, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
I posit that a screen door does not provide any security.
"Any" is too strong a word. For people living in an area with malaria-carrying mosquitoes, that screen door may be more important for security than a solid steel door with a deadbolt. It all depends on what the risks are, what you are protecting, and where your priorities are.
It is rather odd to see this discussion just a few weeks after the IETF issued RFC 4864 to address just this misconception of NAT. How many of the participants have read the RFC? Assuming vendors of cheap consumer IPv6 gateway boxes implement all the LNP (Local Network Protection) features of RFC 4864, is there any reason for these boxes to also support NAT?
As far as I can see the only good reason to put NAT in an IPv6 gateway is because uneducated consumers demand it as a checklist feature. In that case, let's hope that it is off by default and that disabling the NAT does not disrupt any of the other LNP features. That way, when the customer calls the support desk to complain that they are not getting SIP calls from Mom, you can tell them to turn off the NAT and try again.
Precisely. I don't think anyone is suggesting that you should put NAPT in an IPv6 gateway. A few days ago it was suggested by Sam Stickland that a blocker to moving to IPv6 was the lack of NAPT, and the security features that are an integral part of it's functionality.
This thread has been done to death now, but what I originally said was that the use of NAT in IPv4 means that many enterprises don't feel any pressure to move to IPv6, and that furthermore there are many myths and weird design tactics in use that make people (incorrectly) think they need NAT for reasons above and beyond public address conversation. I also expressed a concerned that because of this some nefarious vendors will start selling IPv6 NAT boxes (again, not a good thing!). Time will tell, but I think it's time the thread I seem to have spawned dies ;) S S
On Monday 04 June 2007 18:06, Owen DeLong wrote:
On Jun 4, 2007, at 1:41 PM, David Schwartz wrote:
On Jun 4, 2007, at 11:32 AM, Jim Shankland wrote:
Owen DeLong <owen@delong.com> writes:
There's no security gain from not having real IPs on machines. Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people are liable to start believing it's true :-).
Maybe because it _IS_ true.
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Correct. There's nothing you get from NAT in that respect that you do not get from good stateful inspection firewalls. NONE whatsoever.
Sorry, Owen, but your argument is ridiculous. The original statement was "[t]here's no security gain from not having real IPs on machines". If someone said, "there's no security gain from locking your doors", would you refute it by arguing that there's no security gain from locking your doors that you don't get from posting armed guards round the clock?
Except that's not the argument. The argument would map better to:
There's no security gain from having a screen door in front of your door with a lock and dead-bolt on it that you don't get from a door with a lock and dead-bolt on it.
I posit that a screen door does not provide any security. A lock and deadbolt provide some security. NAT/PAT is a screen door. Not having public addresses is a screen door. A stateful inspection firewall is a lock and deadbolt.
Owen
To add to that: Need I remind those of us who see NAT as some sort of firewall?: NAT is Network Address Translation, and is designed to be for only providing a source of private IP addressing.. it wasn't designed to be a "protection" - it's just a side effect that it does offers any protection at all. People may get lucky because their NAT may check from which interface traffic comes in on (which is a form of inspection, thus indicates a presense of a firewall). But without any sort of packet inspection, someone could trick your NAT into thinking a connection was open when it was not, thus opening a connection to a system on your NAT (that is probably unfirewalled in itself). Or another example: a third party finds out a system on your NAT has a connection open to a host on the internet, so the third party wedges their own foriged packets into the connection, and a NAT without inspection will just foreward it to the internal host without batting an eye.
On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly configured stateful *non*-NAT firewall should be doing for you already.
Valdis.Kletnieks@vt.edu writes:
On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly configured stateful *non*-NAT firewall should be doing for you already.
Thanks for the clarification, Owen and Valdis. We are, of course, 100% in agreement that it is stateful inspection that provides (a measure of) security, and that stateful inspection can be had without NAT. But NAT *requires* stateful inspection; and the many-to-one, port translating NAT in common use all but requires affirmative steps to be taken to relay inbound connections to a designated, internal host -- the default ends up being to drop them. All this can be done without NAT, but with NAT you get it "for free". I can't pass over Valdis's statement that a "good properly configured stateful firewall should be doing [this] already" without noting that on today's Internet, the gap between "should" and "is" is often large. If what you meant to say is that NAT provides no security benefits that can't also be provided by other means, then I completely agree. Jim Shankland
On Mon, 04 Jun 2007 12:20:38 PDT, Jim Shankland said:
I can't pass over Valdis's statement that a "good properly configured stateful firewall should be doing [this] already" without noting that on today's Internet, the gap between "should" and "is" is often large.
Let's not forget all the NAT boxes out there that are *perfectly* willing to let a system make an *outbound* connection. So the user makes a first outbound connection to visit a web page, gets exploited, and the exploit then phones home to download more malware. Yeah, that NAT *should* be providing security, but as you point out, there's that big gap between should and is... :)
Valdis.Kletnieks@vt.edu writes:
Let's not forget all the NAT boxes out there that are *perfectly* willing to let a system make an *outbound* connection. So the user makes a first outbound connection to visit a web page, gets exploited, and the exploit then phones home to download more malware.
Yeah, that NAT *should* be providing security, but as you point out, there's that big gap between should and is... :)
I will happily (well ...) further concede that NAT does not provide *absolute* security. Let me be the first to mention that NAT provides precisely zero protection against: "Hey, kids, just download and run this .EXE to see a cute cartoon of Santa dancing with a polar bear" :-). Jim
Sure, NAT can't prevent users from running with scissors, but sometimes it does block the scissors thrown at the back of their neck whilst they are sleeping :) On 6/4/07, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
On Mon, 04 Jun 2007 12:20:38 PDT, Jim Shankland said:
I can't pass over Valdis's statement that a "good properly configured stateful firewall should be doing [this] already" without noting that on today's Internet, the gap between "should" and "is" is often large.
Let's not forget all the NAT boxes out there that are *perfectly* willing to let a system make an *outbound* connection. So the user makes a first outbound connection to visit a web page, gets exploited, and the exploit then phones home to download more malware.
Yeah, that NAT *should* be providing security, but as you point out, there's that big gap between should and is... :)
At 03:20 PM 6/4/2007, Jim Shankland wrote:
Valdis.Kletnieks@vt.edu writes:
On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly configured stateful *non*-NAT firewall should be doing for you already.
Thanks for the clarification, Owen and Valdis. We are, of course, 100% in agreement that it is stateful inspection that provides (a measure of) security, and that stateful inspection can be had without NAT.
But NAT *requires* stateful inspection; and the many-to-one, port translating NAT in common use all but requires affirmative steps to be taken to relay inbound connections to a designated, internal host -- the default ends up being to drop them. All this can be done without NAT, but with NAT you get it "for free".
NAPT (terminology from RFC 2663, a product of the IETF NAT Working Group) is what you refer to here. This is the most commonly deployed type of NAT, but far from the only. Cisco calls this PAT, for those who like keeping track of the acronyms. (The NAT WG in the IETF put together that RFC specifically because there were so many things being called "NAT"). Many stateful inspection firewall implementations do their work and optionally do the address translation as part of the same processing. Certainly this is very efficient, since the lookups have already been done. For end user sites with client machines, NAT boxes do indeed provide the stateful inspection users really should have, and do so at many price points, from the dirt cheap to the feature rich. Some provide for multiple upstreams, load balancing or failing over when upstreams get congested, providing many of the benefits of multihoming, without the overhead. Obviously this is all best used for end users with client machines.
I can't pass over Valdis's statement that a "good properly configured stateful firewall should be doing [this] already" without noting that on today's Internet, the gap between "should" and "is" is often large.
Depends greatly on the vendor. Appliance firewalls will generally provide the same default configuration out of the box, whether NAT is used or not. That's not to say the default configuration is sufficient for operations, but they'll do the basics just as well whether NAT is on or off.
On Mon, Jun 04, 2007 at 12:20:38PM -0700, Jim Shankland wrote:
But NAT *requires* stateful inspection; and the many-to-one, port translating NAT in common use all but requires affirmative steps to be taken to relay inbound connections to a designated, internal host -- the default ends up being to drop them. All this can be done without NAT, but with NAT you get it "for free".
Except for the costs of NAT, which it could be argued are, long term, higher than the costs of just setting up a firewall properly. There's also no reason why the default policy on a firewall, out of the box, cannot be "no inbound". It's not beyond the realm of possibility that the UI for the firewall device could be such that it was hard-to-impossible to turn off the "no inbound by default" rule.
I can't pass over Valdis's statement that a "good properly configured stateful firewall should be doing [this] already" without noting that on today's Internet, the gap between "should" and "is" is often large.
"In theory, there is no difference between theory and practice. In practice, there is." "There should be no difference between 'should' and 'is'. However, there is." - Matt -- I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. -- Bjarne Stroustrup
JS> Date: Mon, 04 Jun 2007 12:20:38 -0700 JS> From: Jim Shankland JS> If what you meant to say is that NAT provides no security benefits JS> that can't also be provided by other means, then I completely What Owen said is that "[t]here's no security gain from not having real IPs on machines". That is a true statement. Moreover... Provider: "We're seeing WormOfTheDay.W32 from 90.80.70.60." Downstream: "That's our firewall." Provider: "Chances are you have one or more compromised hosts behind your firewall." Downstream: "But we have 150 workstations. How do we find which one(s)?" Bonus points for finding downstreams who understand "NIDS", "monitor port", "state mapping tables", et cetera. :-) In the big picture, I submit that NAT *worsens* the security situation. Of course, the cost falls to "other people" -- a topic that inevitably launches a protracted thread. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita
Jim Shankland wrote:
But NAT *requires* stateful inspection; No, NAT does not require this.
Port NAT mapping one IP to many does, but there are other kinds of NAT. this lack of precision can lead to nasty results when clueless middle managers demand things they don't understand (which is, after all, the way of clueless middle managers.) the technically minded of us can at least not aggravate the situation by being sloppy with our use of language. richard
But NAT *requires* stateful inspection; No, NAT does not require this. In the context of this discussion it does.
Port NAT mapping one IP to many does, but there are other kinds of NAT. This is exactly the NAT that is being spoken of though.
this lack of precision can lead to nasty results when clueless middle managers demand things they don't understand (which is, after all, the way of clueless middle managers.) the technically minded of us can at least not aggravate the situation by being sloppy with our use of language. I find it doubtful that clueless middle manager types read NANOG but your concerns are obviously valid- who knows what someone is going to stumble upon when reading the archives.
I suspect everyone in this thread is completely aware of the differences however. -Don
Valdis.Kletnieks@vt.edu wrote:
On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly configured stateful *non*-NAT firewall should be doing for you already.
What the firewall *should* be doing? The end devices *should* not need protection in the first place, because they *should* be secure as individual devices. But they are not. So you put a firewall in front of them, and that device *should* give them all the protection they need. But sometimes, it doesn't. So you make end devices unaddressable by normal means, and while it shouldn't give them more security, it turns out it does. No matter how much it shouldn't, and how much we wish it didn't, it does. The difference between theory and practice is that in theory, there is no difference, but in practice, there is.
DI> Date: Mon, 04 Jun 2007 15:22:11 -0400 DI> From: Dave Israel DI> So you make end devices unaddressable by normal means, and while it DI> shouldn't give them more security, it turns out it does. No matter DI> how much it shouldn't, and how much we wish it didn't, it does. "Hey, this so-called 'DMZ' feature looks handy. Now I can run a server process... and I'm protected because I'm using a private address!" The security comes from state, full stop. Eddy -- Everquick Internet - http://www.everquick.net/ A division of Brotsman & Dreger, Inc. - http://www.brotsman.com/ Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita ________________________________________________________________________ DO NOT send mail to the following addresses: davidc@brics.com -*- jfconmaapaq@intc.net -*- sam@everquick.net Sending mail to spambait addresses is a great way to get blocked. Ditto for broken OOO autoresponders and foolish AV software backscatter.
On Jun 4, 2007, at 12:22 PM, Dave Israel wrote:
Valdis.Kletnieks@vt.edu wrote:
On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site? Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly configured stateful *non*-NAT firewall should be doing for you already.
What the firewall *should* be doing? The end devices *should* not need protection in the first place, because they *should* be secure as individual devices. But they are not. So you put a firewall in front of them, and that device *should* give them all the protection they need. But sometimes, it doesn't. So you make end devices unaddressable by normal means, and while it shouldn't give them more security, it turns out it does. No matter how much it shouldn't, and how much we wish it didn't, it does.
The difference between theory and practice is that in theory, there is no difference, but in practice, there is.
Actually, I would disagree. A large percentage of attacks, 80% by some estimates, are from behind the firewall. I will argue that the end system needs its own defenses anyway for that reason if none other. That said, the end system is not the only thing one defends. One has an investment in bandwidth and in various other services that one provides for one's-self; the firewall primarily defends those assets, and incidentally gives a first line of defense for your end systems. Defense in depth is also a very commonly used strategy; by limiting the attacks that can happen, in defended places one can focus more heavily on attacks that remain possible. I compare it to the human body's defenses. We have all sorts of things that we use to defend against disease etc; cells that attack specific things, cells that attack things that differ from what is expected, sentinels, and all sorts of other things. We also have at least two firewalls. The skin keeps an awful lot of crud out, meaning we don't have to bring in the big guns, and between the brain and the rest of the body we have a second firewall. NATs are overrated as firewalls. As defenses, they are breached with some regularity. Stateful firewalls are better, if only because they are more intelligent. And firewalls as a class are over-rated as a defense mechanism. There is a long list of attacks that cross them with ease. But as one weapon in the arsenal, they are a simple prophylactic that helps in a material way.
On Monday 04 June 2007 13:54, Valdis.Kletnieks@vt.edu wrote:
On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly configured stateful *non*-NAT firewall should be doing for you already.
Cool, then I need four of these firewalls, and two Class-C (512) worth of IP space that works behind my current ISP at no more than $39.95 each (my basic price for a Dlink, Netgear, etc cable/dsl router with NAT) with no additional cost to my monthly internet - and I will start switching over networks... Yes, I am joking, but the point being that _currently_ NAT serves a purpose; is supported by lots and lots of little "boxes" that customers can plugin, configure, and be on the "net" quickly and easily without having to know about all the "firewall" related stuff; and _does_ do all those neat stateful things for people that have absolutely no interest in knowing about much less learning how to make work. While I agree with the principle being discussed, would that many, many, many more cable in particular and dsl customers of <Insert-Name-of-Large-ISP> had such NAT boxes installed and maybe the rest of us would not be getting quite so much spam from hacked cable/dsl/whatever machines... -- Larry Smith SysAd ECSIS.NET sysad@ecsis.net
On Mon, Jun 04, 2007 at 03:31:00PM -0500, Larry Smith wrote:
On Monday 04 June 2007 13:54, Valdis.Kletnieks@vt.edu wrote:
On Mon, 04 Jun 2007 11:32:39 PDT, Jim Shankland said:
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly configured stateful *non*-NAT firewall should be doing for you already.
Cool, then I need four of these firewalls, and two Class-C (512) worth of IP space that works behind my current ISP at no more than $39.95 each (my basic price for a Dlink, Netgear, etc cable/dsl router with NAT) with no additional cost to my monthly internet - and I will start switching over networks...
Yes, I am joking, but the point being that _currently_ NAT serves a purpose;
Yes, it does -- conservation of address space (and routing table entries, possibly). However, a quick glance at the subject line and the material you quoted should suggest that we're talking about a different topic. - Matt -- I was punching a text message into my phone yesterday and thought, "they need to make a phone that you can just talk into." -- Major Thomb
On Monday 04 June 2007, Valdis.Kletnieks@vt.edu wrote:
Nope. Zip. Zero. Ziltch. Nothing over and above what a good properly configured stateful *non*-NAT firewall should be doing for you already.
Since when are CPE devices 'properly' configured? -- Lamar Owen Chief Information Officer Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu
Jim Shankland wrote:
Owen DeLong <owen@delong.com> writes:
There's no security gain from not having real IPs on machines. Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people are liable to start believing it's true :-).
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Shall I do the experiment again where I set up a Linux box at an RFC1918 address, behind a NAT device, publish the root password of the Linux box and its RFC1918 address, and invite all comers to prove me wrong by showing evidence that they've successfully logged into the Linux box? When I last did this, I got a handful of emails, some quite snide, suggesting I was some combination of ignorant, stupid, and reckless; the Linux box for some reason remained unmolested.
Jim Shankland
Not so. NATing source addresses from multiple source hosts towards the Internet anonymises the source machines so they can not be 'looked at' individually. Additionally, NATing services on separate machines behind a single NATed address anonymises the services behind a single address. Also, it is good to control the Internet addressable devices on your network by putting them behind a NAT device. That way you have less devices to concern yourself about that are directly addressable when they most likely need not be. You can argue that you can do the same with a firewall and a default deny policy but it's a hell of a lot easier to sneak packets past a firewall when you have a directly addressable target behind it than when it's all anonymous because it's NATed and the real boxes are on RFC1918. So really, those who do not think there is a security gain from NATing don't see the big picture. -- Leigh Porter
Also, it is good to control the Internet addressable devices on your network by putting them behind a NAT device. That way you have less devices to concern yourself about that are directly addressable when they most likely need not be. You can argue that you can do the same with a firewall and a default deny policy but it's a hell of a lot easier to sneak packets past a firewall when you have a directly addressable target behind it than when it's all anonymous because it's NATed and the real boxes are on RFC1918. This is patently untrue. Using a firewall such as CheckPoint, which integrates NAT into the object definition, makes it just as likely to accidentally allow traffic to a NAT'd address as it does a real address. Either you are allowing access to the _object_ or you are not.
If you start messing with the NAT table directly then you open up another can of worms- namely additional complexity and a greater opportunity for mistakes.
So really, those who do not think there is a security gain from NATing don't see the big picture. We see the big picture- we see applications with a ton of extra code to handle NAT- code that may contain mistakes and end up being compromised.
We see firewalls that need more code to handle NAT'd applications- code that contains mistakes and can be compromised. We see firewall rule sets that are more complicated and make less than if NAT were not involved. We see security/performance problems that are harder to troubleshoot because we have to dig through a NAT table to figure out which connection is which. Keep it simple. NAT is a terrible terrible hack- and it's sad that it's become so accepted in the maintsream. -Don
Well, give the junky little NAT boxes their due. Grubby little home networks running windoze on one or a few computers cause a lot less trouble in the world when there is a junky little NAT box between the house LAN and the big world outside. Better ways to do it? Absolutely! Easier, cheaper and more widely methods that at least squelch a good bit of the crap? Maybe not... On 6/4/07, Donald Stahl <don@calis.blacksun.org> wrote:
Also, it is good to control the Internet addressable devices on your network by putting them behind a NAT device. That way you have less devices to concern yourself about that are directly addressable when they most likely need not be. You can argue that you can do the same with a firewall and a default deny policy but it's a hell of a lot easier to sneak packets past a firewall when you have a directly addressable target behind it than when it's all anonymous because it's NATed and the real boxes are on RFC1918. This is patently untrue. Using a firewall such as CheckPoint, which integrates NAT into the object definition, makes it just as likely to accidentally allow traffic to a NAT'd address as it does a real address. Either you are allowing access to the _object_ or you are not.
If you start messing with the NAT table directly then you open up another can of worms- namely additional complexity and a greater opportunity for mistakes.
So really, those who do not think there is a security gain from NATing don't see the big picture. We see the big picture- we see applications with a ton of extra code to handle NAT- code that may contain mistakes and end up being compromised.
We see firewalls that need more code to handle NAT'd applications- code that contains mistakes and can be compromised.
We see firewall rule sets that are more complicated and make less than if NAT were not involved.
We see security/performance problems that are harder to troubleshoot because we have to dig through a NAT table to figure out which connection is which.
Keep it simple. NAT is a terrible terrible hack- and it's sad that it's become so accepted in the maintsream.
-Don
Donald Stahl wrote:
Keep it simple. NAT is a terrible terrible hack- and it's sad that it's become so accepted in the maintsream.
Probably mostly because it WORKS for people, it doesn't require you to be a network specialist. Someone just purchases a NAT gateway to connect to their ADSL/cable connection where they have one dynamic IP allocated by their ISP. They get automatic DHCP by the internal ports on the router and all is set, they can connect many computers to the network. They don't have to understand PAT, NAT or policies. This is certainly part of the problem too, that users don't know a lot about their underlying connectivity and why things work the way it does; but that is another discussion. To get rid of NAT and the advantages it has someone would've needed to design stuff differently to begin with. Allocate larger blocks of IPs to customers with more than one computer at home, or default allocate more. Imagine the bureaucracy around that? -- /ahnberg.
On Tue, Jun 05, 2007, Mattias Ahnberg wrote:
Donald Stahl wrote:
Keep it simple. NAT is a terrible terrible hack- and it's sad that it's become so accepted in the maintsream.
Probably mostly because it WORKS for people, it doesn't require you to be a network specialist.
You know, I can't help but see parallels between this and the IP versus other protocols (esp OSI) from what I read during my stint as an undergraduate EE. (No, I'm not an EE now.) I'm sure there's plenty of grumpy telco people out there who think IP is just a hack and OSI/ATM/ISDN were the technologies that were thought out 'right' and should've caught on, damnit! Adrian (won't post again on this thread, sorry!)
Maybe one should consider the customer viewpoint and not just semantic twiddle. When I install one of those little and inexpensive boxes it is for several reasons, not just security. However, the "I hear you knocking, but you can't come in." is invaluable to keep out probes of popular Microsoft points (ports) of vulnerability. In a very practical sense this is added security for the end system. Yes, it is from the Stateful Inspection and not, per se, from address or port translation. That really does not matter because it comes as a package in those cute little boxes. Regarding efficacy of NAT: Have you considered what the typical ISP policy on address assignment and routing will be? Will Comcast announce routes to all my end system addresses to the world? Will Comcast even allow for more than one address per connection? Substitute your vendor of choice here. Be it BT or whatever, until you assure me that my ISP will not interfere with my local SOHO or home network or increase my rate per system added, I will encourage multiplexing of addresses, regardless of IPv4, IPv6, landline telephone number, PO Box, or whatever. Listen to Ahnberg and Dillon. What they say makes much sense and avoids the semantic quibbling that has consumed too much of NANOG mailing list bandwidth. We already know that "All dragons are scotsmen, but not all scotsmen are dragons." - James R. Cutler james.cutler@consultant.com
On Mon, Jun 04, 2007 at 08:04:23PM +0100, Leigh Porter wrote:
Jim Shankland wrote:
Owen DeLong <owen@delong.com> writes:
There's no security gain from not having real IPs on machines. Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people are liable to start believing it's true :-).
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Not so. NATing source addresses from multiple source hosts towards the Internet anonymises the source machines so they can not be 'looked at' individually.
Additionally, NATing services on separate machines behind a single NATed address anonymises the services behind a single address.
Obscurity is not security. If you really want to anonymise traffic, then you've got a lot more work to do than just have all your machines use one IP address. At any rate, proxies (transparent, if necessary) are a better option than NAT for hiding source IPs, as they understand the protocol they're proxying better than your NAT firewall can (unless you build the proxy into your NAT firewall, in which case all you've done is proxy anyway, and you can throw the NAT away). I can think of one counter-example to this argument, and that's SSL-protected services, where having a proxy, transparent or otherwise, in your data stream just isn't going to work. In that instance, though, the SSL is almost always in place to protect some sort of personal information (CC numbers, passwords, etc) -- in which case you've just identified the other end of the connection *anyway*, so anonymity is a large, smelly red herring.
Also, it is good to control the Internet addressable devices on your network by putting them behind a NAT device. That way you have less devices to concern yourself about that are directly addressable when they most likely need not be. You can argue that you can do the same with a firewall and a default deny policy but it's a hell of a lot easier to sneak packets past a firewall when you have a directly addressable target behind it than when it's all anonymous because it's NATed and the real boxes are on RFC1918.
While "protection from mistakes" is a valid reason, it's a pretty weak one. There's no shortage of other things in your system (security things, even!) that don't have NAT to protect them from typos and screwups.
So really, those who do not think there is a security gain from NATing don't see the big picture.
I would say that those who rely on NAT for security are the ones with the narrow world-view. - Matt -- Imagine an orkplace where you were the only non executive: Make them all CEO. Give them all at least one Masters degree and/or a PhD, and the ego trip that comes with that. Now double it. That's education. -- GB, in the Monastery
Matthew Palmer wrote:
I can think of one counter-example to this argument, and that's SSL-protected services, where having a proxy, transparent or otherwise, in your data stream just isn't going to work. Not so. Look at: http://muffin.doit.org/docs/rfc/tunneling_ssl.html
S
On Mon, Jun 04, 2007 at 11:34:30PM +0100, Sam Stickland wrote:
Matthew Palmer wrote:
I can think of one counter-example to this argument, and that's SSL-protected services, where having a proxy, transparent or otherwise, in your data stream just isn't going to work.
Not so. Look at: http://muffin.doit.org/docs/rfc/tunneling_ssl.html
Sorry, that was a *really* poor choice of phrase on my part (so much for my proof-reading skills). It certainly wasn't what I meant to say. What I *meant* to say is that while you *can* tunnel HTTPS (or other SSL/encryption protected) traffic through a regular proxy, it doesn't provide any value that a firewall can't, because you can't get any protocol-specific info out of the data stream (which is what a regular application proxy depends on to do it's work). Everything that I can think of that you can do in a proxy with an HTTPS request can be done in the firewall instead (although you may lack the infrastructure in your firewall to do it while it's built into your proxy, such as restricting IP addresses or request rates or whatever). Your HTTP proxy can't restrict HTTPS traffic based on the requested hostname, it can't cache the request, it can't log the request URL, it can't do any sort of request/response rewriting, and so on. The argumentative person might observe that you can require authentication to use an HTTP proxy, but you can also have logins to firewalls (a la captive portals). Hopefully that's a little more useful (though verbose) than my previous comment. <grin> - Matt
Leigh Porter wrote:
Additionally, NATing services on separate machines behind a single NATed address anonymises the services behind a single address.
Agreed. It can be very useful to not expose the internal topology through address assignment so as to not expose which subnets/desktops/users are accessing certain foreign addresses. This is an even bigger issue in v6 if your stack exposes the MAC address in its choice of stateless autoconfiguration address, as this then gives away not just your internal topology but the vendor of the machines (or at least the ethernet card maker). One can easily imagine attacks based on knowing that a vulnerable and hard-to-upgrade embedded system (an Internet-fax machine, say) was on a particular subnet. Matthew Kaufman matthew@eeph.com
Jim Shankland wrote:
Owen DeLong <owen@delong.com> writes:
There's no security gain from not having real IPs on machines. Any belief that there is results from a lack of understanding.
This is one of those assertions that gets repeated so often people are liable to start believing it's true :-).
*No* security gain? No protection against port scans from Bucharest? No protection for a machine that is used in practice only on the local, office LAN? Or to access a single, corporate Web site?
Shall I do the experiment again where I set up a Linux box at an RFC1918 address, behind a NAT device, publish the root password of the Linux box and its RFC1918 address, and invite all comers to prove me wrong by showing evidence that they've successfully logged into the Linux box? When I last did this, I got a handful of emails, some quite snide, suggesting I was some combination of ignorant, stupid, and reckless; the Linux box for some reason remained unmolested.
Jim Shankland
Mangling the header did nothing for 'security'. The lack of state at the network edge is the security tool here. A firewall provides that state function without the side effect of header mangling. If you really believe in your 1918/nat providing security, do the experiment you propose above, but put in a state mapping for the public address of the nat to the 1918 address of your Linux box. Tony
On 4/06/2007, at 9:52 PM, Sam Stickland wrote:
Jared Mauch wrote:
http://www.icann.org/meetings/lisbon/presentation-doering- ipv6-25mar07.pdf
In answer to two questions at the end of this document:
• what are enterprises waiting for? • should we ditch IPv6, and live with IPv4 + NAT forever?
Personally I hate NAT. But I currently work in a large enterprise environment and NAT is suprisingly popular. I came from a service provider background and some of the attitudes I've discovered towards private addresses in enterprise environments are quite surprising. Aside for the usual proponents of using NAT to hide your internal address infrastructure (which security always seem to insist upon) quite a popular design rule of from seems to be "Only carry public addresses on the public Internet and only carry private addresses on your private network" :-|
If an Enterprise doesn't have a great deal for IP addresses that need to be routed on the public internet, and they thing that NAT is a _good_ design choice, it seems to me that they don't have a great deal of pressure to move to IPv6.
While those are valid concerns, stateless inspection fills the "gap" that NAPT provides in terms of filtering packets, and the privacy extensions for stateless autoconfiguration (RFC3041 and further work, enabled by default on Windows, disabled by default on Mac, BSD, not sure about Linux.) address the "lack" of anonymity. What this thread fails to mention is that NAPT is a band-aid. It won't help us forever, as it still requires one IPv4 address per site (however that is defined), unless it is proposed that ISPs start to put many customers behind a single NAPT - which I strongly hope it's not. While it's entertaining [1] to debate the pros/cons of NAPT's ability to provide security for the 500th time, we're essentially debating the pros/cons of a "technology" that is going to (hopefully) be outdated soon. I suggest we move on. Sam, have you heard any concerns, other than that "NAPT provides us security" one? -- Nathan Ward [1] Ok, it's actually not.
participants (36)
-
Adrian Chadd -
Colm MacCarthaigh -
Daniel Senie -
Dave Israel -
David Schwartz -
Donald Stahl -
Dorn Hetzel -
Edward B. DREGER -
Fred Baker -
Howard C. Berkowitz -
James Hess -
James R. Cutler -
Jared Mauch -
Jason Lewis -
Jeff McAdams -
Jeroen Massar -
Jim Shankland -
Joe Abley -
Joel Jaeggli -
Kradorex Xeron -
Lamar Owen -
Larry Smith -
Leigh Porter -
Matthew Kaufman -
Matthew Palmer -
Mattias Ahnberg -
michael.dillon＠bt.com -
Nathan Ward -
Nicholas Suan -
Owen DeLong -
Perry Lorier -
Richard P. Welty -
Sam Stickland -
Steven M. Bellovin -
Tony Hain -
Valdis.Kletnieks＠vt.edu