[arin-ppml] IPv4 Depletion as an ARIN policy concern

Wed Oct 28 13:59:58 EDT 2009

Chris,

"Create a default rule in your firewall to deny all inbound non-established connections to all internal devices and then poke holes just to devices that need to be accessed externally.  This still requires an active change to allow access and all internal devices are unaccessible by default."

Yes, that is the standard way to configure FW rules, pretty much all FW admins do that now ON TOP OF NAT. However relying on that alone assumes that no-one screws up in the "poking the holes" process which in practice we know is not the case. In fact, one of the most common screw ups is by creating a larger hole then is actually necessary. For example, lets imagine that one of your admins wants to allow OUTGOING FTP from all internal devices.... it's really NOT that hard on many FW's for them (either inadvertently or through inexperience) to open a hole for HTTP to go bi-directionally (INCOMING and OUTGOING) instead. In that case, one screw up and your exposed.... under the NAT scenario you'd still have some protection, as all those internal devices would be non-routable from external sources...thus no one WOULD be able to make HTTP requests of them, even if the FW didn't stop them...since they have no external IP.

For the same vulnerability to take place under the NAT scenario.... you have to have TWO separate screw ups.... some-one has to screw up the FW rule THEN they have to screw up the addressability of the internal devices be assigning them an external IP through NAT.

That's the whole doctrine behind security these days....MULTI-LAYERED DEFENSE.... We KNOW mistakes and screw ups will happen. What you try to do is minimize the impact of a mistake on any ONE layer....so that a single mistake doesn't topple the entire castle.

With the NAT solution...you add an additional layer of defense that must be breached. It must be routable AND it must conform to firewall rules to get through.

"If you can do this with 32 bits I do not see how you would be unable to do it with 80 bits."

Not that simple.... the idea is that you get the ENTIRE reserved private address space to play with to choose what bits mean what.

For instance if you use 10.x.x.x which is pretty common choice for a private network space.... you can subnet the second octet using a /16 internally to control your network segments and then use the third octect to simply indicate the type of host you are assigning (printer,server,workstation, etc). Even with a plethora of address space available under IPV6 I can hardly envision an ISP giving a small/medium business the equivalent of a 10.x.x.x simply so it can conveniently organize it's ip address assignment.

"I would use a different three letters for that: DNS"

And I would respond with one word PROPAGATION. Even assuming that the service could make use of DNS (and not all can) with Propogation and local DNS caching....you have no control of WHEN an individual client picks the right device to connect to..... A user in Boston might resolve the DNS to the new IP and try to connect AT THE SAME TIME a user in Hong Kong was still resolving the old one and trying to connect to it. That situation is FAR from ideal. With NATing you have PRECISE control over when the switch occurs for EVERYONE.

"I don't understand this argument at all.  If you only have 12 IPs that need external access, then you only have 12 IPs that need DNS/RDNS/FW Rules/Usage Tracking, etc - whether the other 288 are rfc1918 IPv4 addresses or globally unique IPv6 addresses... ???"

No.... if you do that THEN you need to be changing the IP address on the NIC of each device every time you have a change in the device you are using to provide services on one of those 12 IP's....which opens it's own can of worms. Not to mention the fact that since most FW's can handle NAT on a Port by Port basis... you might increase the number of IP's you have to manage externals rather dramaticaly.

Christopher Engel

-----Original Message-----
From: Chris Grundemann [mailto:cgrundemann at gmail.com]
Sent: Wednesday, October 28, 2009 12:02 PM
To: Chris Engel
Cc: owen at delong.com; arin-ppml at arin.net
Subject: Re: [arin-ppml] IPv4 Depletion as an ARIN policy concern

On Wed, Oct 28, 2009 at 10:50, Chris Engel <cengel at sponsordirect.com> wrote:
> Owen,
>
> Only addressing the portion of your post that deals with NAT....
>
>
> "First, I'm not really sure why you think NAT is necessary in IPv6.
> It really isn't, and, it really isn't a good idea.  This isn't FUD,
> it's fact.  There's really nothing
> in NAT that helps anything except address conservation. Many people
> mistake
> the fact that NAT requires a stateful inspection gateway to function for
> security being provided by NAT.  The security is not provided by NAT, it
> is provided by stateful inspection"
>
>
> NAT is an EXTREMELY usefull tool to Network/System Admins. While it is
> certainly possible to function without it...the utility of it should
> not be underestimated. Here are examples of it's utility....
>

Just for fun; I have not worked on an enterprise network in a while but a lot of this sounds a bit flimsy, even to me...

>
> 1) It acts as an insurance policy against FW misconfigurations.
> Simply put for most businesses/organizations, the majority of devices
> on your network you do NOT want reachable by external traffic. While
> it is certainly possible to do that with assigning each device a
> public address and using FW rules to deny external access.... in the
> real world we know that FW misconfigurations are not that
> uncommon...particularly when you have complex series of rules at
> multiple individuals responsible for the creation and maintenance of
> them. NAT allows you to utilize private network addresses for ALL your
> internal devices.... which makes them unaccessable to external traffic
> BY DEFAULT...and then allows you to assign public IP's to ONLY those
> devices which are intended to be externaly accessible. Simply screw
> that up (i.e. purposefully taking action to NAT something that
> shouldn't be) then it is to make sure that NONE of your (possibly
> several hundred) FW rules inadvertantly opens a hole  to a device that
> it shouldn't.
>

Create a default rule in your firewall to deny all inbound non-established connections to all internal devices and then poke holes just to devices that need to be accessed externally.  This still requires an active change to allow access and all internal devices are unaccessible by default.

>
> 2) NAT allows Network Admins the flexability to organize thier own
> private address space and the assignment of IP's in ways that logicaly
> make sense to them. For example, on my own network.... by looking at
> the IP address I can instantly tell not only what network segment a
> device is on but what TYPE of address it is as well (Server,
> Workstation, Printer, etc). I don't believe I would be able to achieve
> the same results if I had to limit my assignments to the public
> address range that was provided by my ISP (even if they gave me as
> many addresses as I wanted).
>

If you can do this with 32 bits I do not see how you would be unable to do it with 80 bits.

>
> 3) NAT allows you to abstract your internal infrastructure from the external services you present. This has alot of utility. For example, lets say I provide a service to external users on  (external IP) x.x.x.28   If I want to upgrade or change the device that provides that service NAT makes it very easy. I simply bring up the new device on it's own internal IP.... seperate from the internal IP assigned to the existing device.... and when I want to bring the new device into service all I need to do is switch the NATing on the FW and the new device is now instantly providing that service for external users. Nothing needs to change about how the external users access the device.... they may not even be aware that there was a change of device providing the service.... however all my internal references for both devices remain intact and distinct... which can be very important.  Without NAT, I would either have to bring the new device up on a new public IP and inform all external
>  users of how to access it (which may not even be possible) OR I would
> have to assign the device the existing devices IP address (and
> presumably give the existing device a new one) so that external access
> remained the same. However in that case I'd have to CHANGE ALL MY
> INTERNAL REFERENCES to the devices to make sure they were pointing at
> the right machines. That method would be far, far less efficient the
> utilizing NAT.
>

I would use a different three letters for that: DNS

>
> 4) Conservation of addresses has utility beyond just the
> sparcity/difficulty in acquiring the resource. It saves time and
> effort. Simply put, it is far easier to manage 12 public IP addresses
> then 300. I only need to worry about doing DNS/RDNS/FW Rules/Usage
> Tracking, etc for those 12. Without NAT I'm doomed to either do it for
> all 300 or constantly shuffling around the IP addresses assigned to
> individual NIC's..... either way spells doing alot more work then
> would be truely neccesary otherwise.
>

I don't understand this argument at all.  If you only have 12 IPs that need external access, then you only have 12 IPs that need DNS/RDNS/FW Rules/Usage Tracking, etc - whether the other 288 are rfc1918 IPv4 addresses or globally unique IPv6 addresses... ???

>
> These are just a few of the uses NAT has for me. I don't think I'm
> alone among Network Admins in saying it's a very usefull
> tool....regardless of how many IP's we were able to get assigned to
> us.
>
>

You are used to using it, habits are not all good.

with a smile,
~Chris

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Christopher Engel
>
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN
> Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage
> your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>

--

@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.coisoc.org