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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 19 March 2010 23:51 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E98A63A69F7 for <ietfarch-v6ops-archive@core3.amsl.com>; Fri, 19 Mar 2010 16:51:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.32
X-Spam-Level:
X-Spam-Status: No, score=-0.32 tagged_above=-999 required=5 tests=[AWL=-1.555, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_13=0.6, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lW403nXmAwEE for <ietfarch-v6ops-archive@core3.amsl.com>; Fri, 19 Mar 2010 16:51:15 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 905213A6767 for <v6ops-archive@lists.ietf.org>; Fri, 19 Mar 2010 16:51:12 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1Nslxt-000D7U-Vc for v6ops-data0@psg.com; Fri, 19 Mar 2010 23:50:53 +0000
Received: from [209.85.217.220] (helo=mail-gx0-f220.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <brian.e.carpenter@gmail.com>) id 1Nslxq-000D72-QB for v6ops@ops.ietf.org; Fri, 19 Mar 2010 23:50:50 +0000
Received: by gxk20 with SMTP id 20so138275gxk.18 for <v6ops@ops.ietf.org>; Fri, 19 Mar 2010 16:50:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=ECAktaAUPXySvpRQTlaTUXl+wYk6nETgvJnLGbzONeE=; b=DkUYL5LM2OACzoydBo5kzWD6sjYeLBBjaqFzwZdmzODd62NUomo8vq6+glJKep5coV e0cpf0eAHiApupz96Ir5PmPyfMmHuYkK10wai1tuYQMZfV4ZdvgUnpg+feyMhnp8i2ug 3TA1cSDXclmLUQOCvMuYfLq1i71i0y9k0pCNc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=GW5HN2ITRYtZIl4lHwpIW2RiwZzhyRhCR3EIbfIK9JsfWZ8Fsy1mrCfYj6uCgnlrh1 2JWqCjH8k0Nm12bGNN7jy/gssqrMQSfG60fCRL4wmKPfkAN29hyc1Crj8I2XS6ykrTWP SviT9GpKmuGVI+kvSE6M7UQFBahdlU9kKQSzM=
Received: by 10.90.14.14 with SMTP id 14mr1163615agn.34.1269042649839; Fri, 19 Mar 2010 16:50:49 -0700 (PDT)
Received: from [10.1.1.3] ([121.98.142.15]) by mx.google.com with ESMTPS id 20sm496024ywh.18.2010.03.19.16.50.46 (version=SSLv3 cipher=RC4-MD5); Fri, 19 Mar 2010 16:50:49 -0700 (PDT)
Message-ID: <4BA40DD1.7080306@gmail.com>
Date: Sat, 20 Mar 2010 12:50:41 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Mark Townsley <townsley@cisco.com>
CC: IPv6 Operations <v6ops@ops.ietf.org>, james woodyatt <jhw@apple.com>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09
References: <D6F5ACD2-EB43-477E-9F48-AC3EDB3F7EB4@apple.com> <4BA3BBCF.2090903@cisco.com> <4BA3D1B3.4010501@gmail.com> <4BA3DAAA.10000@cisco.com>
In-Reply-To: <4BA3DAAA.10000@cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

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.
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<jhw@apple.com>
>>>> member of technical staff, communications engineering
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>
>>>
>>>      
>>    
> 
>