[arin-discuss] Trying to Understand IPV6

Owen DeLong owen at delong.com
Tue Sep 14 19:44:41 EDT 2010


> 
> Set aside gear that specifically markets itself as a security device. I expect those will continue to be secure out of the box. All other residential and SOHO access gear may not.
> 
Maybe, but, I bet SOHO access gear that doesn't will not gain much market share.

> SPI has costs. SPI with default deny has additional costs.
> 
SPI costs RAM and CPU. CPU is abundant and cheap compared to residential
speeds these days. RAM is relatively cheap.

Default deny does not cost anything more than SPI. There has to be code that
handles a packet that doesn't match any rule. It doesn't cost any more for that
code to drop than it does to forward.

> In IPv4, these costs are inflicted by the required NAT44 feature, so SPI default deny has no additional cost. Not so in IPv6, with NAT66 not a popular access option, if even ever available at all.
> 
The additional costs are so small that they are noise vs. the market share and
risk of product liability without it, frankly.

I would not want to be the person trying to defend the idea that malicious packets
coming through my CPE device because I chose not to implement a basic SPI with
default deny was not a foreseeable event. If you don't think the law will eventually
catch up to the idea that this should be a product liability issue, I think you are
sadly mistaken.

>> I'm quite willing to listen to countering points of view though -
>> could you please explain why the market forces that push b and d will
>> not be present in IPv6 but would somehow be present if only we added
>> NAT66 to the equation?
>> 
>> -r
>> 
>> 
>>   
> 
> I am trying to counter the assumption that the majority of interaction not required devices will continue to deny inbound traffic out of the box with a full blown SPI firewall turned on, with hole punching and other resultant required ALG's and end user conveniences developed, enabled, tuned, tweaked and supported.
> 
If you don't have NAT and you just use SPI, you mostly don't need ALGs. The hole punching is
handled by uPNP (for better or worse) and there are other alternatives as well.

I'm not sure why you think any vendor would skip these features just because they don't
implement header mangling.

> I believe that the major factor for default deny being ubiquitous is due to NAT44 being similarly ubiquitous.
> 
That may have been true when NAT first hit IPv4 because security was still an afterthought
at the time. However, in today's environment, I think that would not be the case with any
responsible vendor implementing CPE for any significant market share.

> Why would support costs be lower for consumer routers with SPI default deny than for routers without?
> 
Because consumers that buy routers without SPI will call the router vendor when their PC gets
pwn3d. Even if only 10% blame the router vendor instead of their computer vendor, that's
still a large enough support cost to tip the balance.

> Most hosts already have adequate host based protection available, there is no reason to expect low cost device makers to continue duplicating the effort for little cause.
> 
You're joking, right?

Most hosts doe not have anywhere near adequate protection enabled. Even those that have it available
are largely not implemented.

> I support the notion that NAT66 should be available for those who want it without vilification and demonization. I dont support it as a sanctioned solution to any problem better global address management can solve instead. I dont believe anything we do here will have any real effect on NAT66 availability or whether these devices will continue to have default deny.
> 
The problem with making NAT66 available without vilification or demonization as you call it is that
it will increase costs for everyone, especially those who don't want NAT66 and aren't deploying
it. There may be a small cost to SPI, but, there is a HUGE cost to NAT and it is rarely born by those
actually using NAT.

Owen




More information about the ARIN-discuss mailing list