[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
v6 & DSL / Cable modems [was: Private use of non-RFC1918 IP space
Ricky Beam wrote:
> On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk
> <stephen at sprunk.org> wrote:
>> Non-NAT firewalls do have some appeal, because they don't need to
>> mangle the packets, just passively observe them and open pinholes
>> when appropriate.
> This is exactly the same with NAT and non-NAT -- making any anti-NAT
> arguments null.
> In the case of NAT, the "helper" has to understand the protocol to
> know what traffic to map.
> In the case of a stateful firewalling ("non-NAT"), the "helper" has to
> understand the protocol to know what traffic to allow.
> Subtle difference, but in the end, the same thing... if your gateway
> doesn't know what you are doing, odds are it will interfere with it.
> In all cases, end-to-end transparency doesn't exist. (as has been the
> case for well over a decade.)
Yes, an ALG needs to understand the packet format to open pinholes --
but with NAT, it also needs to mangle the packets. A non-NAT firewall
just examines the packets and then passes them on unmangled.
This mangling can be a serious source of problems. With UDP, it can
introduce checksum errors. With TCP, not only do you have possible
checksum errors, you also have to mangle the sequence numbers in both
directions if the length of the payload changes. The mangling will
inherently break standard IPsec and other "shim" layers like HIP. And
let's not forget that NAT makes widespread deployment of any L4
alternative to TCP and UDP (e.g. SCTP) virtually impossible, forcing
every new transport or shim protocol to inefficiently ride on top of TCP
Some protocols, e.g. SIP/RTP, also work fine through a stateful firewall
even without an ALG in most cases -- but not when you add in NAT.
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 3241 bytes
Desc: S/MIME Cryptographic Signature