Re: Rate of growth on IPv6 not fast enough?

[joel jaeggli <joelja () bogus com>]

On 4/20/2010 6:34 PM, Karl Auer wrote:
> 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

I love this statement particularly in the context of enterprise networks...

When you pop the label off an l3 vpn or pseudo wire in the wrong place 
where does the packet go? Does one even know? does the outside network 
have overlapping addresses with the inside one, does it have a default 
route? is there filtering?

Is it an opportunity for information leakage?

How many parallel networks with overlapping private addressing domains 
are there on router? your your l3 vpn providers routers? How far will a 
private address get you when it leaks. These sorts of things I wonder 
about when I contemplate doing syslog on a q-in-q vlan over a vpls.

> > 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.