A statefull firewalls is NOT an appropriate substitute for NAT, nor is NAT an appropriate substitute for a statefull firewall. They compliment each other and overlap in certain areas but they don't fulfill one another's roles.
The object, the entire goal, of NAT is to abstract the organizations internal infrastructure from it's external presence. That has functionality in terms of security certainly but it also has functionality operationally. I'll try to be brief as this could get quite long... In terms of security, NAT... - Acts as a compensating control to help mitigate the impact of firewall misconfigurations. The firewall itself, by definition, cannot substitute for NAT in this arena. It is presumed in this scenario that the firewall (filters) is the point of failure itself. Relying on that layer/mechanism alone means you have a single point of failure. NAT adds an additional layer or (partial) protection. - NAT helps to obscure the internal network architecture. This makes it more difficult to profile that network for attack. Although, as been pointed out elsewhere, it is not impossible for an attacker to conduct some profiling even in the presence of NAT. It does require considerably more effort and sophistication to do so with NAT in place. The analogy being that while wall safes can be defeated, they still provide a significant measure of protection over leaving your valuables laying out in the open. - NAT aids in privacy as it helps retard the ability of tracking an individual devices activity by IP address from external sources. In terms of operability, NAT... - NAT reduces the impact of switching vendors by reducing the degree to which an organization must renumber. The private address scheme on an internal network can rename the same and only the external address scheme needs be changed. This has been thoroughly discussed elsewhere. - NAT is very useful for the reverse function as well. It allows a network to be flexible in it's distribution and redistribution of internal infrastructure without the need for any changes to the external advertisement of services. Services can be moved between devices, internal networks, moved from a single device to a load balancer....with PAT even split from one device (say providing SMTP & HTTP) without any change in the external advertisement of such services at the network level. This is incredibly useful, it can be accomplished simply on a single interface and, is protocol/application independent and avoids many of the propagation/caching/timing issues caused by other methods of service advertising such as DNS. - NAT allows for simplification of address management. Typically the number of devices that need an external advertisement of services (i.e. expect INBOUND traffic) is only a small fraction of the totality of internal devices. NAT allows you to manage that small pool of external addresses on a single device/interface without any need to impact internal address assignments. These are just a few of the more obvious areas where NAT provides useful functionality. Note, that I certainly don't mean to imply that NAT does not cause it's share of problems and complications as well. However, every organizations usage case will be different. As with every technology each organization will need to assess the costs and benefits of it in regards it's own unique situation and arrive at the conclusion that makes the most sense for it's own usage. Different organizations WILL reach different conclusions. The concept that a significant number of organizations won't find the benefits of NAT far outweigh the costs is (IMO) willful blindness. The internet needs to support a wide diversity of users with a wide diversity of interests. I believe that such flexibility, far more then the concept of end-to-end transparency or end-to-end reachability is what lead to the true success of the internet....the freedom for each organization to utilize it in the manner that best fits that individual organizations needs. It is admirable to support efforts that NAT NEED not be deployed for those organizations who deem it problematic.... it is wrong-headed to attempt to PREVENT organizations who find NAT useful from deploying it on their OWN network boundaries in an IPv6 world. Christopher Engel > -----Original Message----- > From: Fred Baker [mailto:[email protected]] > Sent: Friday, April 30, 2010 11:28 AM > To: Chris Engel > Cc: Keith Moore; [email protected] > Subject: Re: [SPAM] - Re: [nat66] Terminology: Definition for > "IPv6 Realm"? - Email has different SMTP TO: and MIME TO: > fields in the email addresses > > > Is your intent here the same as what is built by firewalls? > If so, NAT is a solution, but it is not required to achieve > the goal. I suspect that what you're looking for is a > firewall, not a NAT. > > You might read > http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security > "Recommended Simple Security Capabilities in Customer > Premises Equipment > for Providing Residential IPv6 Internet Service", James Woodyatt, > 24-Apr-10, <draft-ietf-v6ops-cpe-simple-security-11.txt> > > which is a set of requirements we are developing in v6ops for > stateful firewalls for IPv6 networks, which one would most > likely implement in a CPE. > > > On Apr 30, 2010, at 4:12 PM, Chris Engel wrote: > > > You WILL have Realms (I believe even very similar to those > described > > in RFC 2663) in IPv6. > > > > > > 1) I am convinced that there WILL be NAT in IPv6....very similar to > > the flavors available in IPv4. It's an open question > whether it will > > be defined in an RFC but it will exist. Why? Because too > many people > > like myself will demand it of our vendors. With that kind > of economic > > pressure, some vendor somewhere will bite and you'll have > NAT whether > > you like it or not. I just got done telling our hosting > company (which > > we spend several hundred grand on annually) that we will require a > > NAT-like solution for IPv6 and if they don't provide one > and another > > hosting service does we will be looking to switch vendors. How many > > customers like that do you think it will take before it becomes > > worthwhile for some-one to invest in building NAT66 > devices? The only > > thing not having any RFC's for them will do is make it likely that > > there are no standards, just a hodge-podge of vendor specific > > solutions. > > > > > > 2) Even without NAT, you will STILL have the concept of > realms. There > > are networks, that by design, have very limited or NO > reachability to > > the general internet. That's why ULA-R exists. In the > absence of NAT, > > I'm sure a very common deployment scenario for Enterprises > will be to > > have 2 Network address architectures. Every device on the private > > network will have a ULA address and then the devices which are > > intended to have some external connectivity will also be > assigned a PA > > address. The routers/firewalls on the network boundary will be > > designed NOT to route ULA traffic...either outgoing or > incoming. That > > would be my deployment scheme if I had to do IPv6 without > NAT. Though > > frankly, the plans right now are to avoid IPv6 entirely > until there is > > some NAT solution. Possibly looking at doing some sort of NAT46 > > gateway solution if necessary and staying on IPv4 local. > > > > > > > > I'm far from the only Network Manager that feels this way. I make > > purchasing decisions for my enterprise and I've talked to guys in > > similar positions at other enterprises that feel the same way about > > NAT that we do. The only reason you aren't seeing vendors biting on > > this already is that IPv6 isn't really on most enterprises radar > > screens yet. In essence there is no real need or demand for IPv6 > > itself yet. > > > > Right now IPv6 (for Enterprises at least) is just a huge > unjustified > > cost center...that people who are being pro-active may > dabble a little > > bit with to build up some experience for the time when > their may be a > > real need to support it. > > > > > > > > > > > > > > Christopher Engel > > > >> -----Original Message----- > >> From: [email protected] [mailto:[email protected]] On > >> Behalf Of Fred Baker > >> Sent: Friday, April 30, 2010 1:39 AM > >> To: Keith Moore > >> Cc: [email protected] > >> Subject: [SPAM] - Re: [nat66] Terminology: Definition for "IPv6 > >> Realm"? - Email has different SMTP TO: and MIME TO: fields in the > >> email addresses > >> > >> > >> I would (did) argue that the issue isn't reachability... > >> > >> On Apr 30, 2010, at 6:30 AM, Keith Moore wrote: > >> > >> > >> I agree that the concept of ??? (reachability > >> boundaries?) needs a name. > >> > >> Keith > >> > >> > >> Fine. The concept I described is relevant, > even if (as > >> both Brian and I point out) it is not the same as the one RFC > >> 2663/3103 talk about. We'll use a different word so you > don't have to > >> worry about it. > >> > >> > >> On Apr 30, 2010, at 6:14 AM, Keith Moore wrote: > >> > >> > >> > >> Even if one accepts the need for > v6-v6 NAT (I do > >> not) that's still not a justification for IPv6 addressing realms. > >> > >> > >> Look at the "cc" line of this email. > >> > >> On Apr 30, 2010, at 3:11 AM, > Keith Moore > >> wrote: > >> > >> > >> > >> Why is there a need > for such a > >> concept as "IPv6 realm"? > >> > >> It seems to me that > if we ever > >> create IPv6 realms in the sense that realms exist in IPv4 > (i.e. if we > >> make IPv6 addresses ambiguous), we've irrevocably broken IPv6. > >> > >> And if we end up creating a > >> subtly different concept in IPv6 - something like realms > without the > >> potential for address assignment conflicts > >> - it will be confusing to call such things realms. > >> > >> But I really think the right > >> thing to do is to make explicit that there is only one "realm" for > >> the entire IPv6 address space. > >> > >> Keith > >> > >> > >> We got a definition for "IPv4 > >> realm", based on RFC 2663 (but also RFC 3103). > >> Both RFC's are IPv4 oriented, > >> not providing an explicit definition for an "IPv6 realm". > >> > >> This question might > be related > >> to NAT66, because the IPv4 realm concept is originating from NAT44. > >> > >> Does anyone know a > correspondent > >> definition/reference for IPv6 realm? > >> > >> If not, I'd like to offer an > >> initial proposal for discussion, - a common realm term for > IPv4 and > >> IPv6: > >> > >> (IPv4 or IPv6 address) > >> realm: is defined as a set of addresses, which share all a common > >> prefix, that are mutually reachable (thus, within a single > IP routing > >> domain). > >> > >> Note: "IPv6 realm" definition > >> based on the GLOBAL UNICAST ADDRESS format (ยง 2.5.4/RFC > 4291) because > >> this is a hierarchical format using a "global routing > prefix", which > >> is assigned to a "site" (i.e. sth like a REALM). > >> Comments would be appreciated, > >> Albrecht > >> _____ > >> RFC 2663 IP Network > >> Address Translator (NAT) Terminology and Considerations > >> 2.1. Address realm or realm > >> > >> > >> > >> > >> An address realm > is a network > >> domain in which the network addresses > >> are uniquely assigned to > >> entities such that datagrams can be routed > >> to them. Routing protocols > >> used within the network domain are > >> responsible for finding > >> routes to entities given their network > >> addresses. Note that this > >> document is limited to describing NAT in > >> IPv4 environment > and does not > >> address the use of NAT in other types > >> of environment. (e.g. IPv6 > >> environments) > >> > >> > >> RFC 3103 Realm Specific > >> IP: Protocol Specification > >> 3. Terminology > >> Private Realm > >> > >> A routing realm > that uses > >> private IP addresses from the ranges > >> (10.0.0.0/8, > >> 172.16.0.0/12, 192.168.0.0/16) specified in > >> [ > >> RFC1918 > >> ], or addresses that are > >> non-routable from the Internet. > >> > >> Public Realm > >> > >> A routing realm with > >> unique network addresses assigned by the > >> Internet > Assigned Number > >> Authority (IANA) or an equivalent address > >> registry. > >> > >> > >> > >> > >> _______________________________________________ > >> nat66 mailing list > >> > >> [email protected] > >> > >> https://www.ietf.org/mailman/listinfo/nat66 > >> > >> > >> > >> _______________________________________________ > >> nat66 mailing list > >> [email protected] > >> > >> https://www.ietf.org/mailman/listinfo/nat66 > >> > >> > >> > >> http://www.ipinc.net/IPv4.GIF > >> > >> > >> _______________________________________________ > >> nat66 mailing list > >> [email protected] > >> > >> https://www.ietf.org/mailman/listinfo/nat66 > >> > >> > >> > >> > >> > >> http://www.ipinc.net/IPv4.GIF > >> > >> > >> > >> > >> http://www.ipinc.net/IPv4.GIF > >> > >> > > http://www.ipinc.net/IPv4.GIF > > _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
