Failure modes: NAT vs SPI

Adam Armstrong lists at
Wed Mar 2 03:59:11 CST 2011

This thread makes me sad.


On 03/02/2011 19:09, Jay Ashworth wrote:
> ----- Original Message -----
>> From: "Owen DeLong"<owen at>
>> 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

More information about the NANOG mailing list