[arin-discuss] Trying to Understand IPV6

[Joe Maimon]

Owen DeLong wrote:
>> 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.
>    

My crystal ball is not nearly as clear as yours.

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

SPI costs product development and support. SPI causes state table 
exhaustion issues for p2p and similar multitude of connections traffic. 
Port scanning through an SPI isnt any fun, as an example. SPI default 
deny creates support issues and product perception issues when end users 
believe or are told that they need to manually tune or turn it off.

Is it not possible that "Turn off the firewall on your router" wont 
become part of the standard support script?
> 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.
>    

There does not need to be any code that implements any rules. That 
should cost less. Have you not seen access devices that dont even offer 
the option to turn off NAT44? Why is it so hard to believe that the 
option of not including any firewall features at all will be attractive 
to many a maker of low end access devices.

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

You may be correct that product liability and security expectations will 
be a growing factor favoring SPI default deny. However, I am unconvinced 
that it will be great enough to compensate for the removal of NAT, which 
gives it to you as a by product and is not optional.

>>      
> If you don't have NAT and you just use SPI, you mostly don't need ALGs.

I cant accept that on face value. If the protocol embeds the return 
information in the packet, the SPI firewall will need to know where it 
is to ensure that return packets are allowed. If this information was 
discernible from the generic l3 header, why would the protocol feel a 
need to embed it? If it is discernible from the generic l3 header, why 
would any special ALG be needed for NAT that would not be needed for SPI?

If there is no ALG, without uPNP or similar end node to gateway 
signalling, which is ugly, embedding return information wont work any 
better with SPI than it does with NAT+SPI.

>   The hole punching is
> handled by uPNP (for better or worse) and there are other alternatives as well.
>    

Some of which were just discussed in this thread. More product 
development and support costs.

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

Because if they dont implement header mangling, they now need to justify 
the effort and cost involved in implementing these features and having 
them turned on by default.

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

At least you acknowledge that there is a question there. We can predict 
all we want, but we should not be blase about it.

Security is still an afterthought, as well as a scapegoat.

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

Might those calls be countered by the additional calls from those trying 
to do their gaming|voip|p2p|cams and claiming that the router is getting 
in their way with its firewall? I just dont think this is as cut and 
dried it has been made out to be.

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

Nope. Linux iptables is actually what powers most of these devices SPI. 
I cant imagine that a modern distro's iptables is any worse than the 
embedded ancient kernel. The rest are adequate enough. The bar is not 
all that high in this device space.

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

Is this because they feel they have no compelling reason to turn it on? 
You have made my case. What makes you think device makers are any better?

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

I appreciate the honesty. You dont want anyone to use NAT66, because it 
makes it harder (increases costs) for other people who develop and 
implement independent-stream callback protocols, whether they should be 
doing so or not, whether they are entitled to lower their costs or not 
by championing denying users the features that the users claim they want.

They always have the option of simply denying nat users the joys and 
wonder of their protocol and application.

Frankly, I think designing protocols in that fashion needs to have its 
drawbacks just to maintain some balance and those protocols are going to 
need ALG's anyways. I am also unconvinced that the trade off is as high 
as you make it to be and that it will not be lowered simply by having a 
lesser percentage of end nodes with nat on the net.

Most things seem to work fairly well on todays net, even with its high 
density of natted end nodes, especially when they are not designed by 
anti-nat idealouges.

Joe