[LINK] www.ipv6.org.au/summit

Karl Auer kauer at biplane.com.au
Sun Aug 31 18:38:51 AEST 2008


On Sun, 2008-08-31 at 09:37 +0200, Kim Holburn wrote:
> Karl Auer <kauer at biplane.com.au>  wrote:
> >> Perhaps my point would be better stated as "NAT provides no security
> >> benefit that cannot be obtained from a simple packet filter".
> 
> I don't agree with this really.  A NAT router provides quite good  
> security even if installed by an idiot.  A simple packet filter is  
> considerably harder to install, requires some knowledge of the network  
> topology 

Argh!

A NAT (as now provided in a typical bit of CPE and not counting any
additional packet filtering features that might be in the box)
essentially provides a packet filter that says "allow established, block
everything else".

This is extremely simple, one size fits all, and it can easily be
pre-packaged with any CPE. In fact it already is - it's a side-effect of
NAT.

Compared to what CPE manufacturers already demand of the home user -
port forwarding and DMZ configurations and what-all else - turning such
a filter on and off would be a doddle. Even configuring exceptions would
certainly be no more difficult than configuring port forwarding. 99% of
customers would never have to look at it anyway.
 
> and uses public IP numbers which are not cheap for  
> consumers.

Well - yes! This whole discussion started with the observation that IPv6
made NAT obsolete. With IPv6 you can dump NAT and good riddance.
Unfortunately with dual stack you'll still need it for your expensive,
scarce IPv4 addresses.

>  A simple packet filter gives away all sorts of info.

Er, not really, no. In fact the simpler it is the less info it gives
out. You may be referring to whether it returns ICMP messages? Otherwise
I can't think what you might mean.

>   It may be possible to flood it in such a way as to  
> allow access to one or more machines behind it.  A NAT router does not  
> allow this because there simply is no route in.

It's just software; if a packet filter can fail under load so can NAT.

I'm supposing now, but it seems very unlikely to me that a packet filter
- especially a simple packet filter - would fail under load. NAT
processing is way more complex; I'd expect NAT to fail first. Also, the
likelihood of a failure mode that forwards MORE packets than it should
seems even more remote.

If there is "simply no route in" with NAT, then there's "simply no route
in" with a packet filter. It's all just bits.

> today's internet.  For instance the ability for any host on the  
> internet to contact any other host at full speed leads to serious  
> security issues.  Pushing NAT up the chain is bad but it is a response  
> to some of the serious security problems with today's internet.

The ability for a sharp knife to cut things makes sharp knives
dangerous. Let's blunt all knives!

The ability for any host to talk at high speed to any other host is the
*whole point* of the Internet.

Regards, K.

PS: I'd like to hear more specifics about these "serious security
issues". Why they are they the fault of the network protocol? How  does
NAT ameliorate them? The phrase as you have used it smells a bit like a
George W Bush speech to me, full of unspecified, unnamed dangers... FUD,
in other words.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
http://www.biplane.com.au/~kauer/                  +61-428-957160 (mob)

GPG fingerprint: DD23 0DF3 2260 3060 7FEC 5CA8 1AF6 D9E3 CFEE 6B28
Public key at  : random.sks.keyserver.penguin.de





More information about the Link mailing list