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

[Mark Townsley <[e-mail]>]

On 3/20/10 12:50 AM, Brian E Carpenter wrote:
> Mark,
>
> I dislike 'default deny' as much as anyone. After all,
> I'm an author of RFC 4864.
>
> But I'm afraid that the simplicity of 'default deny' has long
> ago won the hearts and minds of enterprise network managers.
>    
The Enterprise edge is very different than the Residential edge. This 
draft is targeting the Residential edge.

- Mark
> I can see the virtues of rate limiting, but I see it as too
> contentious to attempt to get it into the *simple* security
> draft. Sadly.
>
> Regards
>     Brian
>
> On 2010-03-20 09:12, Mark Townsley wrote:
>    
>> On 3/19/10 8:34 PM, Brian E Carpenter wrote:
>>      
>>> Mark, I'm not going to reply to your specific question.
>>>
>>>        
>> That's too bad.
>>      
>>> The one most clear result from the ISP survey I will report
>>> on during the IETF is that the biggest gap in products holding
>>> up general v6 deployment is CPE.
>>>
>>>        
>> Understood.
>>      
>>> I think it's a matter of great urgency to get this draft
>>> out as an RFC; it's a couple of years too late.
>>>
>>>        
>> It's more the implementations that are late, but I get your point.
>>      
>>> So I want to say: let's not add *anything*. Let's just
>>> push it out in a matter of weeks.
>>>
>>>        
>> All we are doing is talking about allowing what is now a binary on/off
>> in the draft now to be a variable between 0 and some maximum instead.
>> The default could still well be what we have now, 0, though I would like
>> it to be something else.
>>
>> I'm not sure that leaving this out will help advance the draft more
>> quickly. Folks like me, who are quite happy with their native IPv6
>> service for the past couple of years with no IPv6 firewall, think of
>> cpe-simple-security as a sword in the heart of IPv6 and end-to-end
>> transparency. Including "Rule 7" is something that would go a long way
>> towards at least me stepping back and not making an enormous ruckus when
>> this draft hits last call.
>>
>> We've already talked about the idea in v6ops, it's been documented in a
>> draft for at least a little while, and after Hiroshima I got some
>> indication that this was something people would like to have. The basic
>> concept comes from Dave Oran, who included it in various presentations
>> for years.
>>
>> So, aside of your fears of changing anything in the draft at all, what
>> do you think of the idea?
>>
>> - Mark
>>      
>>> The same applies to draft-ietf-v6ops-ipv6-cpe-router
>>> of course.
>>>
>>> Regards
>>>      Brian Carpenter
>>>
>>> On 2010-03-20 07:00, Mark Townsley wrote:
>>>
>>>        
>>>> I would like to propose some form of "ParanoidOpeness" (Rule #7) from
>>>> draft-vyncke-advanced-ipv6-security-01 to be brought into the
>>>> simple-security draft.
>>>>
>>>> The basic idea is that rather than blocking otherwise unauthorized
>>>> inbound connections outright, the CPE rate-limits them according to a
>>>> variable setting. When that setting is 0, all incoming packets are
>>>> dropped. When set to its maximum, all packets are permitted (as if the
>>>> firewall function is configured off). In-between, the CPE rate-limits
>>>> incoming packets to reduce probing of the home network, but to allow
>>>> just enough packets through that, if a host inside responds, a pinhole
>>>> is opened for the communication to occur. Of course, the hard part is
>>>> what the default setting should be, but I'd like to get a sense first of
>>>> whether we can bring this function in.
>>>>
>>>> James, I think I remember you being warm to the idea in some (jabber?)
>>>> comments during the meeting in Hiroshima when I presented this first.
>>>>
>>>> Thanks,
>>>>
>>>> - Mark
>>>>
>>>> On 3/4/10 12:06 AM, james woodyatt wrote:
>>>>
>>>>          
>>>>> everyone--
>>>>>
>>>>> Once again, I'd like to ask for some discussion and feedback on this
>>>>> draft.  Is there any reason this revision of the draft should not
>>>>> proceed to Working Group Last Call at this time?
>>>>>
>>>>>
>>>>> -- 
>>>>> james woodyatt<[e-mail]>
>>>>> member of technical staff, communications engineering
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>            
>>>>
>>>>
>>>>          
>>>
>>>        
>>
>>      
>