Donald Stahl wrote:
Ever try to set up a VPN between two offices using the same address space?
Sure, very easily, by using NAT between the subnets.
NAT is still evil though, the problems it causes operationally are just plain not worth it.
Can you clarify this claim? What about managing NAT is allegedly difficult. Are you unable to easily map public addresses with private addresses on your own networks?
Stateful inspection provides security benefits.
Neither SI nor NAT provides any security. It is the rules commonly implemented on top of them that can provide security. Please be consistent in the use of these terms to avoid confusing the issue. Jeff McAdams wrote:
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.
Crux of the thread for sure. In an academic context NAT only swaps header addresses, however, in the world of network operators and end-users all NAT devices do SI and filtering. It is the filtering, blocking connections initiated from public addresses, that provides "NAT security". That is still "NAT security" if only because it is characteristic of virtually all NAT devices, and not the default or even a common configuration of non-NAT network devices and applications. Perhaps it is difficult to understand this vernacular "NAT" after studying Comer, Stevens et al, but when you've run the equivalent of 'sh conn' regularly for several years the narrow, some would say ivory tower, definition of NAT tends to morph into one based on actual implementations. Since this mailing list is by and for network operators as opposed to academics perhaps we could ask the later (NANAGs?) to use footnotes(1) to clarify their meaning? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Sure, very easily, by using NAT between the subnets. Have at it. Nothing like trying to reach 10.10.10.10 nad having to put in a dns entry pointing to 172.29.10.10, NAT'ing the address on your side to
Can you clarify this claim? What about managing NAT is allegedly difficult. Are you unable to easily map public addresses with private addresses on your own networks? Easily map them? Sure- I can do my external tcpdump, see some funny
their side and from their side back to your side, and adding the rules. That's definitely simpler than allow a -> b for service c. traffic, then match that up with the dynamic nat's. That's a lot easier than just going "oh, hey, it's this user" without any further steps. I, for one, give up. No matter what you say I will never implement NAT, and you may or may not implement it if people make boxes that support it. Clearly neither of us will change our minds so why bother. I'm sure we've both gotten supportive emails in private and both know we are "right." In the end it isn't going to change a thing. -Don
I, for one, give up. No matter what you say I will never implement NAT, and you may or may not implement it if people make boxes that support it. Clearly ...
This was supposed to be a private reply and was not meant to go to the list. My apologies. I will also refrain from further responses- something I definitely should have done 20 messages ago... -Don
Sure, very easily, by using NAT between the subnets.
Have at it. Nothing like trying to reach 10.10.10.10 nad having to put in a dns entry pointing to 172.29.10.10
End-users prefer hostnames to IPs. DNS hostnames are valid on both sides due to either local zone files or a DNS protocol-NAT. It's a no-brainer to implement and a lot easier than using public address space given the relatively complex firewalling and filtering that requires.
NAT'ing the address on your side to their side and from their side back to your side, and adding the rules. That's definitely simpler than allow a -> b for service c.
Not simpler than running something like "fixup protocol dns" on a VPN termination.
I, for one, give up. No matter what you say I will never implement NAT, and you may or may not implement it if people make boxes that support it.
Most of the rest of us will continue to listen to both sides and continue to prefer NAT, in no small part because of the absurd examples and inconsistent terminology NATophobes seem to feel is necessary to make their case. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
On Tue, 05 Jun 2007 17:44:40 PDT, Roger Marquis said:
Sure, very easily, by using NAT between the subnets.
Have at it. Nothing like trying to reach 10.10.10.10 nad having to put in a dns entry pointing to 172.29.10.10
End-users prefer hostnames to IPs. DNS hostnames are valid on both sides due to either local zone files or a DNS protocol-NAT. It's a no-brainer to implement and a lot easier than using public address space given the relatively complex firewalling and filtering that requires.
So now the cruft extends and embraces, and you have to play DNS view games based on whether it's on company A's legacy net, company B's legacy net, or the DMZ in between them, and start poking around in the middle of DNS packets to tweak the replies (which sort of guarantees you can't deploy DNSSEC). And if the company aquires *another* one with rfc1918 on their legacy net, then you get to play "as seen from A, B, or C, or this DMZ, or that DMZ".. I think somebody on this list mentioned that due to corporate acquisitions, there were legitimate paths between machines that traversed 5 or 6 NATs. But yeah, "Sure, very easily". Whatever you say...
So now the cruft extends and embraces, and you have to play DNS view games based on whether it's on company A's legacy net, company B's legacy net, or the DMZ in between them, and start poking around in the middle of DNS packets to tweak the replies (which sort of guarantees you can't deploy DNSSEC).
Are you proposing that every company use publicly routable address space? How about the ones that don't qualify for a /19 and so are dependent on addresses owned by their upstream? To change ISPs for example, would it be simpler to change the IP address of every node in the company or to run NAT on the gateways? How about multi-homing? Can you even do it without NAT on a network too small assign an AS? In the mid-90s I was CSO at a company whose internal networks were publicly routable thanks to a /16 they owned (though they really only needed a few /24s). In my experience, for every example of how complex NAT is there are at least 10 counter-examples of how an equivalent non-NATed network is more complex, less flexible, less reliable, and less secure. -- Roger Marquis Roble Systems Consulting http://www.roble.com/
On 6/06/2007, at 2:53 PM, Roger Marquis wrote:
So now the cruft extends and embraces, and you have to play DNS view games based on whether it's on company A's legacy net, company B's legacy net, or the DMZ in between them, and start poking around in the middle of DNS packets to tweak the replies (which sort of guarantees you can't deploy DNSSEC).
<IPv4 junk>
You clearly missed the start of this conversation, and my summaries in the last couple of days, about which I am not surprised. We were discussing IPv6, the lack of NAT was brought up as being viewed as a blocker for security reasons, and solutions were presented so that it no longer is, assuming adequate education is provided. -- Nathan Ward
On 6/5/07, Roger Marquis <marquis@roble.com> wrote:
Are you proposing that every company use publicly routable address space? How about the ones that don't qualify for a /19 and so are dependent on addresses owned by their upstream?
This discussion evolved from an IPv6 discussion, so there's plenty of address space for everybody in the assumptions, and you can have a /48 even if a /64 is overkill.
To change ISPs for example, would it be simpler to change the IP address of every node in the company or to run NAT on the gateways?
Unlike the security discussions, that's one area where NAT really does make life easier for medium-large companies (either 1-1 NAT or PNAT will do.) It lets you number your internal space as 10/8, regardless of what ISP or ISPs you're using externally, so if you have to change one of your ISPs, you don't have to renumber anything except possibly a couple of externally-visible servers and gateways. Of course, that only remains true until some merger or acquisition mashes your 10/8 address space into another company's 10/8 address space , at which point you've still got work to do unless you were both careful about taking random subnets of 10/8, e.g. 10.x/16 for randomly selected x>10. ---- Thanks; Bill Note that this isn't my regular email account - It's still experimental so far. And Google probably logs and indexes everything you send it.
Thus spake "Roger Marquis" <marquis@roble.com>
I, for one, give up. No matter what you say I will never implement NAT, and you may or may not implement it if people make boxes that support it.
Most of the rest of us will continue to listen to both sides and continue to prefer NAT, in no small part because of the absurd examples and inconsistent terminology NATophobes seem to feel is necessary to make their case.
The thing is, with IPv6 there's no need to do NAT. What vendors have (so far) failed to deliver is a consumer-grade firewall that does SI with the same rules on by default that v4 NAT devices have. Throw in DHCP PD and addressing (and renumbering) are automatic. This is simpler than NAT because no "fixup" is required; a v6 firewall with SI and public addresses on both sides just needs to inspect packets, not modify them. The same device will probably be a v4 NAT device; nobody is trying to take that away because it's a necessary evil. However, NAT in v6 is not necessary, and it's still evil. S Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov
On Jun 6, 2007, at 8:59 AM, Stephen Sprunk wrote:
The thing is, with IPv6 there's no need to do NAT.
Changing providers without renumbering your entire infrastructure. Multi-homing without having to know or participate in BGP games. (yes, the current PI-for-everybody allocation mindset would address the first, however I have to admit I find the idea of every small enterprise on the planet playing BGP games a bit ... disconcerting)
However, NAT in v6 is not necessary, and it's still evil.
Even ignoring the two above, NAT will be a fact of life as long as people who are only able to obtain IPv6 addresses and need/want to communicate with the (overwhelmingly IPv4 for the foreseeable future) Internet. Might as well get used to it. I for one welcome our new NAT overlords... Rgds, -drc
On Wed, 6 Jun 2007 09:45:01 -0700 David Conrad <drc@virtualized.org> wrote:
On Jun 6, 2007, at 8:59 AM, Stephen Sprunk wrote:
The thing is, with IPv6 there's no need to do NAT.
Changing providers without renumbering your entire infrastructure.
Multi-homing without having to know or participate in BGP games.
(yes, the current PI-for-everybody allocation mindset would address the first, however I have to admit I find the idea of every small enterprise on the planet playing BGP games a bit ... disconcerting)
However, NAT in v6 is not necessary, and it's still evil.
Even ignoring the two above, NAT will be a fact of life as long as people who are only able to obtain IPv6 addresses and need/want to communicate with the (overwhelmingly IPv4 for the foreseeable future) Internet. Might as well get used to it. I for one welcome our new NAT overlords...
For all those people who think IPv4 NAT is quite fine, I challenge them to submit RFCs to the IETF that resolve, without creating worse or more even more complicated problems, the list of problems here. All the IPv6 RFCs do ... : http://www.cs.utk.edu/~moore/what-nats-break.html I've spent a number of years wondering why people seem to like NAT (don't bother trying to convince me, my burnt stubs of fingers have convinced me it's evil), and the only feasible conclusion I can come to is that it is a chance to live out the "invisible man" fantasy they had in their childhood. We've all had that fantasy I think, and we'd all like to live it out ... In IPv6, if you want to have a globally reachable service, you bind it to a global address, and you protect the rest of the services/layer 4 protocol endpoints on that host that use global addresses via an SI firewall, preferably on the host itself. If you don't want to have a service globally reachable, then you don't bind it to a global address - bind the service only to the to the ULA addresses on the host. Then it'll be globally unreachable regardless of whether there is a SI firewall active or not (although if people start convincing upstreams and peers to accept their ULA routes external to their own private network ... well, they made that choice, they'll have to live with the security consequences) -- "Sheep are slow and tasty, and therefore must remain constantly alert." - Bruce Schneier, "Beyond Fear"
I think at this point, everything that could possibly be said about NAT and security has been said. Unless you have something profound to add which hasn't been mentioned in this thread before, please refrain from adding to this thread. -Alex (for the mailing list team)
On 7/06/2007, at 3:59 AM, Stephen Sprunk wrote:
Thus spake "Roger Marquis" <marquis@roble.com>
I, for one, give up. No matter what you say I will never implement NAT, and you may or may not implement it if people make boxes that support it.
Most of the rest of us will continue to listen to both sides and continue to prefer NAT, in no small part because of the absurd examples and inconsistent terminology NATophobes seem to feel is necessary to make their case.
The thing is, with IPv6 there's no need to do NAT. What vendors have (so far) failed to deliver is a consumer-grade firewall that does SI with the same rules on by default that v4 NAT devices have. Throw in DHCP PD and addressing (and renumbering) are automatic. This is simpler than NAT because no "fixup" is required; a v6 firewall with SI and public addresses on both sides just needs to inspect packets, not modify them.
The same device will probably be a v4 NAT device; nobody is trying to take that away because it's a necessary evil. However, NAT in v6 is not necessary, and it's still evil.
People keep saying that this device doesn't exist, infact it does. First let me say that vendors haven't failed, as they (for the most part) haven't tried yet. I'd consider them to have failed if they delivered a bunch of IPv6 boxes without SI, and that hasn't happened. (ok, Cisco delivered an IPv6 capable CPE in the 8xx series, but IPv6 on those things is hardly a consumer-configurable setting to enable.) Anyway, my Apple Airport Extreme base station (the new draft-802.11n one) does IPv6 SI and IPv4 NAT perfectly fine, infact, that was the primary reason I bought it. It also does 6to4 or static tunnels if you don't have native IPv6. 6to4 with IPv6 SI is the default out of the box configuration. If you just configure the IPv4 stuff, you get IPv6 for free, by default. IPv6 SI /was/ disabled by default in the original firmware, and while the firmware update is pretty hard to miss when configuring the thing (it pops up and says "new software, install?" or similar), I believe it leaves the SI checkbox where you'd left it - the new default only kicks in if you do a factory reset. However, I believe that new units ship with the new software, so I suspect it's not really a widespread problem in the grand scheme of things. This was the first IPv6 capable consumer router, as far as I'm aware, and this issue was found and fixed within weeks. I've got no doubt that other vendors will learn from this mistake. -- Nathan Ward (Disclaimer: On reading my post it sounds like advertising - I don't work for, and am not otherwise affiliated with, Apple.)
participants (9)
-
alex＠pilosoft.com -
Bill Stewart -
David Conrad -
Donald Stahl -
Mark Smith -
Nathan Ward -
Roger Marquis -
Stephen Sprunk -
Valdis.Kletnieks＠vt.edu