Rate of growth on IPv6 not fast enough?

Wed Apr 21 01:34:15 UTC 2010

On Tue, 2010-04-20 at 12:59 -0700, Owen DeLong wrote:
> On Apr 20, 2010, at 12:31 PM, Roger Marquis wrote:
> > NAT _always_ fails-closed
> Stateful Inspection can be implemented fail-closed.

Not to take issue with either statement in particular, but I think there
needs to be some consideration of what "fail" means.

Dealing with an unwanted but foreseeable error condition, like running
out of memory, is not a failure mode. It is a controlled event. NOT
dealing with it is a failure mode.

So a properly written program (or properly constructed device) will deal
with whatever error conditions the designer was able to anticipate, and
will hopefully deal with them intelligently. Power failure and physical
damage are harder to handle than others, but on high-end equipment even
some of those are considered and managed. Ideally the designer will have
considered all conditions that can possibly arise, but the ideal is not
achievable. There will *always* be conditions a program or device is
unable to handle or possibly even detect.

When a situation arises that is beyond the control of the program or
device, was not anticipated by the designer, or if the designer made a
mistake, we enter the realm of an actual failure. And all bets are off.
NAT (for example) could fail in any way at all - including by (say)
inappropriately sharing a mapping. If processes are running on a shared
platform - say NAT, routing and packet filtering - failure of any part
could cause failure of any other part. In some cases (I seem to recall
that recent Californian power failures were an example) the error
handling itself can cause another error condition and another
opportunity for failure.

Reading through the security alerts from any vendor is a pretty sobering
process - stuff fails open more often than you might expect.

So I think we should be very cautious about saying that things "fail
open" or "fail closed".

We should be especially cautious about it when the functionality we are
interested in is really no more than a happy side effect of some other
functionality. NAT's "security", to the extent that it exists at all, is
a side effect of what it is intended to do, which is translate and map
addresses.

Regards, K.

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

GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156
Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20100421/7605a360/attachment.sig>