[secdir] SECDIR Review of draft-ietf-roll-applicability-ami

Chris Lonvick <clonvick@cisco.com> Fri, 13 December 2013 19:42 UTC

Return-Path: <clonvick@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0E61AE3D8; Fri, 13 Dec 2013 11:42:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0mZOluJziXx; Fri, 13 Dec 2013 11:42:05 -0800 (PST)
Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 1F24C1AE3DD; Fri, 13 Dec 2013 11:42:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1511; q=dns/txt; s=iport; t=1386963717; x=1388173317; h=date:from:to:subject:message-id:mime-version; bh=4Vy2zrncktrxr1zxFIsGchYA1QiV7psnHfJKlhwoiRA=; b=MJy/+qp/rhD99hsfIXSJFV4oAzskCsrkBb6FxhZI5ky3XQK8vW5OAusQ kF3nfTiawCXYFR0kM0uZwq2RUM/XXNuFMzev2i2/XYy0a21RJYHxdLynS ArHMHFIVdJE0eRXIOiEIQ8/8KBvt2ljxueGCVZq/UjfAAMW0SFwVf3Qyz o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EABViq1KrRDoG/2dsb2JhbABZgwo4ulkWdIJkAoF+iBUOyw4Xk1IEiUOgZ4NL
X-IronPort-AV: E=Sophos;i="4.95,481,1384300800"; d="scan'208";a="100409998"
Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 13 Dec 2013 19:41:56 +0000
Received: from sjc-xdm-112 (sjc-xdm-112.cisco.com [171.71.188.44]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rBDJfs6a024378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Dec 2013 19:41:54 GMT
Date: Fri, 13 Dec 2013 11:41:54 -0800
From: Chris Lonvick <clonvick@cisco.com>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-roll-applicability-ami.all@tools.ietf.org
Message-ID: <alpine.LRH.2.00.1312131107430.24081@sjc-xdm-112.cisco.com>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format="flowed"; charset="US-ASCII"
Subject: [secdir] SECDIR Review of draft-ietf-roll-applicability-ami
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 13 Dec 2013 19:42:07 -0000

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

The document is incomplete but it appears that the authors know where they 
want to go with it.

I would recommend that the Security Considerations section point to the 
Security Considerations section of RFC 6550 (RPL) and say that the 
roll-applicability-ami document is a description of the applicability of 
6550 to the ami, therefore the considerations of 6550 apply.

The authors note that other security mechanisms may be used, which would 
mean that the security functions of RPL would not be needed.  I would 
recommend that a section of the Security Considerations be added for each 
instance where the RPL security mechanism are not to be used.  Each of 
those sections should show how the replacement mechanisms will meet the 
requirements of the RPL security services that are described in 6550.

I also see that the authors are also trying to address the initial 
deployment and incremental deployments, which is laudable.  The authors 
may wish to look at restructuring the Security Considerations section to 
address these things through the FCAPS model or something similar. 
(http://en.wikipedia.org/wiki/FCAPS)

Regards,
Chris