Re: [secdir] secdir review of draft-ietf-v6ops-ipv6-cpe-router
Fred Baker <fred@cisco.com> Wed, 11 August 2010 16:29 UTC
Return-Path: <fred@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 A89E63A6A50; Wed, 11 Aug 2010 09:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.223
X-Spam-Level:
X-Spam-Status: No, score=-110.223 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 0Jp-ShJZZl9s; Wed, 11 Aug 2010 09:29:41 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 17C383A6A33; Wed, 11 Aug 2010 09:29:41 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.55,354,1278288000"; d="scan'208";a="238860035"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 11 Aug 2010 16:30:17 +0000
Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7BGUAK7027760; Wed, 11 Aug 2010 16:30:11 GMT
Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Wed, 11 Aug 2010 09:30:17 -0700
X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Wed, 11 Aug 2010 09:30:17 -0700
Mime-Version: 1.0 (Apple Message framework v1081)
From: Fred Baker <fred@cisco.com>
X-Priority: 3 (Normal)
In-Reply-To: <65E2BBE0-0BF0-4695-A46F-05BFB9E666F8@cisco.com>
Date: Wed, 11 Aug 2010 09:30:03 -0700
Message-Id: <9909FF61-A552-4DEB-BB64-728B22605E7D@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>
To: Ole Troan <ot@cisco.com>
X-Mailer: Apple Mail (2.1081)
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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:29:42 -0000
Ack. Pick up the other two changes, which are minute, post it, and give the IESG the diffs URL. Thanks. On Aug 11, 2010, at 9:02 AM, Ole Troan wrote: > 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
- [secdir] secdir review of draft-ietf-v6ops-ipv6-c… Scott G. Kelly
- Re: [secdir] secdir review of draft-ietf-v6ops-ip… Scott G. Kelly
- Re: [secdir] secdir review of draft-ietf-v6ops-ip… Ole Troan
- Re: [secdir] secdir review of draft-ietf-v6ops-ip… Scott G. Kelly
- Re: [secdir] secdir review of draft-ietf-v6ops-ip… Chris Donley
- Re: [secdir] secdir review of draft-ietf-v6ops-ip… Ole Troan
- Re: [secdir] secdir review of draft-ietf-v6ops-ip… Fred Baker
- Re: [secdir] secdir review of draft-ietf-v6ops-ip… Fred Baker
- Re: [secdir] secdir review of draft-ietf-v6ops-ip… Ole Troan
- Re: [secdir] secdir review of draft-ietf-v6ops-ip… Ole Troan