Re: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router

Ole Troan <ot@cisco.com> Wed, 11 August 2010 16:57 UTC

Return-Path: <ot@cisco.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A13473A6968; Wed, 11 Aug 2010 09:57:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.028
X-Spam-Level:
X-Spam-Status: No, score=-10.028 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 iTrJhtmdbuzI; Wed, 11 Aug 2010 09:57:02 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0A6443A6A74; Wed, 11 Aug 2010 09:57:01 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.55,354,1278288000"; d="scan'208";a="146506373"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2010 16:57:38 +0000
Received: from [10.0.0.8] (ams3-vpn-dhcp6343.cisco.com [10.61.88.198]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7BGvZRU028148; Wed, 11 Aug 2010 16:57:36 GMT
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Ole Troan <ot@cisco.com>
X-Priority: 3 (Normal)
In-Reply-To: <9909FF61-A552-4DEB-BB64-728B22605E7D@cisco.com>
Date: Wed, 11 Aug 2010 18:57:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <81DD3B0D-072D-4563-BBFE-89DA96912902@cisco.com>
References: <1280871146.382928184@192.168.2.231> <76AC5FEF83F1E64491446437EA81A61F7CF5048723@srvxchg> <1281120642.72688236@192.168.2.229> <E4601768-508F-4069-9C71-A0CFCEC90EAD@cisco.com> <00A6D384-5CD8-4E7A-A342-C19CA8C640FA@cisco.com> <65E2BBE0-0BF0-4695-A46F-05BFB9E666F8@cisco.com> <9909FF61-A552-4DEB-BB64-728B22605E7D@cisco.com>
To: Fred Baker <fred@cisco.com>
X-Mailer: Apple Mail (2.1081)
X-Mailman-Approved-At: Wed, 11 Aug 2010 10:33:03 -0700
Cc: Chris Donley <C.Donley@cablelabs.com>, secdir@ietf.org, Ron Bonica <ron@bonica.org>, draft-ietf-v6ops-ipv6-cpe-router.all@tools.ietf.org, cpe-router@external.cisco.com, iesg@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Aug 2010 16:57:03 -0000

Fred,

> Ack. Pick up the other two changes, which are minute, post it, and give the IESG the diffs URL. Thanks.

thanks again. posted.
the diffs are at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ipv6-cpe-router-07.txt

(also the previously discussed L-16/W-6 changes are included.)

cheers,
Ole

> 
>> Fred,
>> 
>>> Note from the document shepherd...
>>> 
>>> The process is that the IESG expects an updated draft in response to comments. However, they usually consider the draft for a while and then TELL you that they want it. It is on the telechat for approval Thursday, and per https://datatracker.ietf.org/doc/draft-ietf-v6ops-ipv6-cpe-router/ has no "discuss" ballots and "enough positions to pass", which appears to be two "no objection" ballots.
>>> 
>>> Tell me: what is required to address Scott's comments? Is this a big change or a small one? If it is a small enough change, I would suggest that you address it, address Stewart's comment ("expand acronym MLD on first usage"), and pick up three idnits points that have crept in since the draft was last posted:
>>> 
>>> Checking references for intended status: Informational
>>> ----------------------------------------------------------------------------
>>> 
>>> == Outdated reference: draft-ietf-6man-ipv6-subnet-model has been published
>>>   as RFC 5942
>>> 
>>> == Outdated reference: A later version (-05) exists of
>>>   draft-ietf-6man-node-req-bis-04
>>> 
>>> == Outdated reference: A later version (-12) exists of
>>>   draft-ietf-v6ops-cpe-simple-security-11
>>> 
>>> And then post it and send a URL to the diffs to the IESG so they can see what you did. That would allow them to send it on tomorrow. If doing that in the next few hours isn't reasonable, then wait for the IESG remarks, which I would expect will sound a lot like what I just said but with a different date.
>> 
>> thanks for the clarification, the changes are in my opinion small.
>> 
>> the security considerations are limited to tightening up language and make it clear what we "expect" from the CPE simple security draft:
>> 
>>      <section title="Security Considerations">
>>        <t>It is considered a best practice to filter obviously malicious
>>        traffic (e.g. spoofed packets, "martian" addresses, etc.).  Thus, the
>> -        IPv6 CE router should support basic stateless egress and ingress
>> -        filters.  The CE router should also offer mechanisms to filter
>> +        IPv6 CE router ought to support basic stateless egress and ingress
>> +        filters.  The CE router is also expected to offer mechanisms to filter
>>        traffic entering the customer network; however, the method by which
>>        vendors implement configurable packet filtering is beyond the scope of
>>        this document.</t>
>> 
>>        <t>Security requirements:<list style='format S-%d:'>
>> -            <t>The IPv6 CE router SHOULD support
>> -            <xref target="I-D.ietf-v6ops-cpe-simple-security"></xref>.</t>
>> +            <t>The IPv6 CE router SHOULD support <xref
>> +            target="I-D.ietf-v6ops-cpe-simple-security"></xref>. In
>> +            particular, the IPv6 CE router SHOULD support
>> +            functionality sufficient for implementing the set of
>> +            recommendations in <xref
>> +            target="I-D.ietf-v6ops-cpe-simple-security"></xref>
>> +            section 4. Ths document takes no position on whether such
>> +            functionality is enabled by default or mechanisms by which
>> +            users would configure it.</t>
>> 
>> in addition we have on the advice from the DHC WG removed the last part of this requirement:
>>         <t>If the IPv6 CE router requests both an IA_NA and an IA_PD
>>         in DHCPv6, it MUST accept an IA_PD in DHCPv6 Advertise/Reply
>> -         messages, even if the message does not contain any addresses
>> -         (IA_NA options with status code equal to NoAddrsAvail).</t>
>> +         messages, even if the message does not contain any
>> +         addresses.</t>
>> 
>> cheers,
>> Ole
>> 
>> 
> 
> http://www.ipinc.net/IPv4.GIF
>