nanog mailing list archives
Failure modes: NAT vs SPI
From: Jay Ashworth <jra () baylink com>
Date: Thu, 3 Feb 2011 14:09:52 -0500 (EST)
----- Original Message -----
From: "Owen DeLong" <owen () delong com>
On Feb 3, 2011, at 8:29 AM, Jay Ashworth wrote:This is the crux of the argument I've been trying, rather ineptly, to make: when it breaks, *which way does it fail*. NAT fails safe, generally.So does any decent stateful inspection firewall. That's why your argument doesn't hold water.
Perhaps we disagree on the definition of "decent". An SPI Firewall is code, running on a router. It drops packets which should not otherwise be routed by the base routing code running on that router, which knows how to reach the internal network's addresses, and packets are sent to it from the Net-at-large. In the NAT4 case, those internal addresses are unknown to the NAL, and the NAT code, as configured by the person operating the edge router, is the only way for packets to get into the LAN; if the NAT code falls over on the router, then packets cannot get in, since the outside world *cannot get packets to that router with addresses which it will further route inbound*. That's the expansion of "fails safe". Let us now examine the alternate case. In this case, that original SPI case I mentioned above, we're assuming routable addresses behind that firewall -- that is, the NAL *does* know how to aim packets at a *specific host inside my LAN*. Those packets get to my edge router, and the SPI firewall drops the appropriate packets before they're actually handed to the routing core, and sent inwards. If the firewall code fails or is inadvertanly turned off, what happens? Why, the router does what it's designed for, it routes. Those external packets. In, to my hosts. With no firewall in the way. Sorry to have to show my work, but that's my work: please explain how you feel that those two situations do *not* make NAT safer in the edge case where an SPI firewall fails in such a fashion as not to drop the packets asked of it? All that's necessary to cause that failure is to say "turn it off", whereas causing a comparable failure on the NAT side requires *defining specific new rules that target specific internal hosts by IP address*, which is a much more complex task, which effectively cannot be accomplished by accident, unlike accidentally disabling a firewall. Cheers, -- jra
Current thread:
- Re: quietly...., (continued)
- Re: quietly.... Owen DeLong (Feb 04)
- Re: quietly.... Jack Bates (Feb 05)
- RE: quietly.... Lee Howard (Feb 06)
- Re: quietly.... isabel dias (Feb 06)
- Re: quietly.... Owen DeLong (Feb 06)
- Re: quietly.... Valdis . Kletnieks (Feb 04)
- Re: quietly.... Blake Dunlap (Feb 04)
- Re: quietly.... Jay Ashworth (Feb 04)
- Re: quietly.... Jack Bates (Feb 03)
- Re: quietly.... david raistrick (Feb 03)
- Failure modes: NAT vs SPI Jay Ashworth (Feb 03)
- Re: Failure modes: NAT vs SPI Iljitsch van Beijnum (Feb 03)
- Message not available
- Re: Failure modes: NAT vs SPI Iljitsch van Beijnum (Feb 07)
- Re: Failure modes: NAT vs SPI Owen DeLong (Feb 07)
- Re: Failure modes: NAT vs SPI Lamar Owen (Feb 10)
- Re: Failure modes: NAT vs SPI Owen DeLong (Feb 10)
- Re: Failure modes: NAT vs SPI Joel Jaeggli (Feb 10)
- Re: Failure modes: NAT vs SPI Jay Ashworth (Feb 07)
- Re: Failure modes: NAT vs SPI Valdis . Kletnieks (Feb 07)
- Re: Failure modes: NAT vs SPI Jack Bates (Feb 07)
- Re: Failure modes: NAT vs SPI Iljitsch van Beijnum (Feb 07)