[arin-ppml] Set aside round deux

Chris Engel cengel at sponsordirect.com
Wed Aug 4 14:12:07 EDT 2010


Kevin Kargel wrote:

> > This has been gone over here before but please do explain what NAT
> > breaks that wouldn't have otherwise been dealt with by statefull
> > inspection?
> >
> There are many examples but to pick the perhaps most common
> consumer app talk to anyone who has an Xbox and wants to host
> games.  They can probably quote you chapter and verse about
> "Strict NAT" and they will be more than happy to tell you
> about the woes of getting it to work.
>
> Yes you can make it work by taking the time to configure port
> forwarding through NAT or to place the game console in the
> DMZ, but these are really workarounds to defeat NAT and also
> defeat any perceived security offered by NAT.

I don't have much experience on the consumer side of things but, I assume if the consumer has a reasonably secure network boundary device it will have some sort of DENY ALL IN rule anyway. Which means they are going to need to adjust thier FW to do any sort of hosting in the first place. Is it really that much more difficult to create a NAT entry for the desired device on the FW then it is to create the Allow In rule on the FW? If so, is that a problem with the protocol archetecture or with the UI of the device itself?

I've always found it just as easy to setup NAT entries on the devices I've worked with as I have to setup FW rules....albiet I always have a static IP pool to work with on the external interface of my devices..... not sure how much more complicated it gets when you (presumably) are having to use public IP's assigned through DHCP.

The benefit of NAT is that it provides a layer of abstraction between the public and private address spaces. An SI firewall doesn't do that, it simply acts as a Gate-Keeper for traffic at the boundary....an incredibly usefull function no doubt...perhaps quite more usefull then abstraction....but not at all the same thing... and not the equivalent of a Gate-Keeper AND Abstraction.

With NAT, an external intruder can't compromise the web-server that my printer manufacturer oh so helpfully included as a feature of that device even IF my SI firewall is misconfigured to allow his packets through. He has no way of knowing the printer exists and no way of addressing packets to it to probe for it. He can only probe what I have explicitly externaly advertised through NAT.

That solution doesn't force me to deploy a seperate address scheme for public and private addresses on EACH device on my network. Just to have one internal address scheme and a mapping to the bits of it I want publicaly exposed on my FW.

Furthermore, the level of abstraction allows me to shift stuff around internaly without changing anything about the external advertisement of services. Thus if I want to move a particular public service from machine #1 to machine #2, I don't need to renumber those machines....and I don't need to call up Charlie, the Admin over at the guys using that service and say "Hey we just switched Service X from x.x.x.27 to x.x.x.52 make the changes on your FW so your users can get to the new machine we're hosting it on."  ... I just change the NAT mapping on my FW for those machines. That to me is incredibly usefull.


Again, I have no problem with people saying "You know NAT is really, really problematic for the type of situations I deal with..... I really wish I didn't have to employ it." That's a perfectly valid stance to take....and the good news is that IPv6 will allow you to avoid deploying it.

That stance is a far cry from "NAT is really, really problematic for me..... therefore it MUST be really, really problematic for you....and you are only deluding yourself that it is usefull.... under our new regieme THOU SHALT NOT USE IT..... we will make no allowence for it."




Christopher Engel




More information about the ARIN-PPML mailing list