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

Fred Baker <fred@cisco.com> Thu, 04 March 2010 23:58 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 9DCA33A8D70 for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 4 Mar 2010 15:58:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.495
X-Spam-Level:
X-Spam-Status: No, score=-108.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1, 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 Xs6tJn5CvEto for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 4 Mar 2010 15:58:24 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DB8CC3A8CC9 for <v6ops-archive@lists.ietf.org>; Thu, 4 Mar 2010 15:58:23 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1NnKuM-0007ez-Vn for v6ops-data0@psg.com; Thu, 04 Mar 2010 23:56:46 +0000
Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from <fred@cisco.com>) id 1NnKuK-0007en-Mk for v6ops@ops.ietf.org; Thu, 04 Mar 2010 23:56:44 +0000
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.49,583,1262563200"; d="scan'208";a="160954530"
Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 04 Mar 2010 23:56:43 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o24Nucpj024678; Thu, 4 Mar 2010 23:56:39 GMT
Subject: Re: I-D.ietf-v6ops-cpe-simple-security-09
Mime-Version: 1.0 (Apple Message framework v1077)
Content-Type: text/plain; charset="us-ascii"
From: Fred Baker <fred@cisco.com>
In-Reply-To: <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com>
Date: Thu, 04 Mar 2010 15:56:17 -0800
Cc: james woodyatt <jhw@apple.com>, IPv6 Operations <v6ops@ops.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <929CA789-3B68-4B60-A623-311D072B4F17@cisco.com>
References: <D6F5ACD2-EB43-477E-9F48-AC3EDB3F7EB4@apple.com> <0E826480-B510-4907-9F38-6119C0D7523B@cisco.com>
To: Mark Baugher <mbaugher@cisco.com>
X-Mailer: Apple Mail (2.1077)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Mar 4, 2010, at 3:25 PM, Mark Baugher wrote:

> I think this is an important document that seems to be ready to be published.  I have a couple of concerns:
> 
> 1. Rec-2.  Why not site-scope?

   REC-2: Packets which bear in their outer IPv6 headers multicast
   destination addresses of equal or narrower scope (see section 2.7 of
   IP Version 6 Addressing Architecture [RFC4291]) than the configured
   scope boundary level of the gateway MUST NOT be forwarded in any
   direction.  The DEFAULT scope boundary level SHOULD be organization-
   local scope, and it SHOULD be configurable by the network
   admininistrator.

I'm not even sure I understand the recommendation. To be sure, RFC 4291 knows nothing of an "organization-local" scope; what is likely meant here is "site-local". I'm also not sure I understand the reasoning behind it; I would understand if it said to drop datagrams addressed to wider scopes ("all customers of a given ISP") or narrower scopes (if you mean a specific subnet, which one is that?) but I don't understand why you would drop the datagram if the scope of its address were exactly as configured on the firewall.

> 2. Rec-42.  Pardon me if I'm being dense, but what are you saying here?  That service providers cannot manage the device from an exterior interface?

I should hope they couldn't without the network administration actively doing something to permit them to. As we have discussed privately, a protocol that enables an entity outside my administrative domain to control equipment witin my administrative domain without my explicit authorization is a security issue.

> There are many SHOULDs and some should be MUSTs.  I have a long list of nits and such.  I'll send the markups directly to you, James.  Is this Last Call or is this going into Last Call soon?

Last call will not happen before IETF 77.

> Mark
> 
> 
> On Mar 3, 2010, at 3:06 PM, 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
>> 
>> 
>> 
> 
> 

http://www.ipinc.net/IPv4.GIF