Re: I-D.ietf-v6ops-cpe-simple-security-09

[Mark Townsley <[e-mail]>]

On 3/20/10 11:55 PM, Fred Baker wrote:
>>>> Rate-limiting unsolicited inbound connections rather than rejecting them provides greater end-to-end transparency while still providing protection against address and port scanning attacks as well as overloading of slow links or devices within the home.
>>>>
>>>>          
>>> SIlly question. Why do you believe that? An address or port scanning attack is not intended to overload a network, it is intended to find an address port that can be used or attacked.
>>>        
>> The sentence is referencing two different things. One, the possibility that uninvited packets might overload some device or slow link (something I consider unlikely, but has been identified as a concern by some), the other is, indeed, designed to make blind port and address scanning less likely to succeed in a given amount of time.
>>
>> - Mark
>>      
>>>   Making the scan take more time doesn't prevent it from reaching its target. In what way does rate limiting an address or port scan provide protection?
>>>        
> With all due respect, when I set up security for my home or office, and when Cisco InfoSec sets up security for its home offices (of which mine is one), they're not asking about making an attack take ten minutes vs five. They're asking about preventing an attack from succeeding. Now, we can discuss the logic of the notion that "the bad guys are out there and the good guys are in here", but given the assumption, we need to be rational about the threats we are trying to prevent from succeeding.
>    
There is nothing irrational about making a hacker's job more difficult. 
That is the basis behind every measure in the document now. None of them 
make it impossible for a system to be compromised, just more difficult.

Virtually all of the firewall functions in this draft are imposing a 
certain kind of limited end to end connectivity for the average user on 
the IPv6 Internet. The tradeoff for this limitation is the promise of 
security. I have little doubt that a determined hacker will be able to 
get around each and every measure identified in the document. At best, 
the bar is simply being raised to make the hacker's job a bit more 
difficult, perhaps reducing the number which are actually successful. 
The argument we are having is over how high to raise the bar, and at 
what cost in terms of transparency. I'd like us to have to possibility 
of keeping it just a slight bit lower for IPv6 than what we have for 
IPv4. I don't see why we should set the bar at the same level until 
there is evidence that the machines running IPv6 (Windows Vista, 7, 
MACOSX - each which are shipped with update programs and embedded IPv6 
personal firewalls) are as vulnerable as the whole gamut of IPv4 systems 
available today.

"Unsolicited" incoming connections are a huge benefit for application 
simplicity. In various consumer surveys, remote access to devices in the 
home is listed as one of the most important features that residential 
subscribers would like to see more of. The various firewall control 
protocols are far from being completed and add their own complexity - 
complexity that in a real threat analysis might show just as many 
security issues as just leaving the door open a crack. And, that's what 
I am advocating here. A knob that allows the door to be open, shut, or 
something in-between.

- Mark