Re: [Roll] [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used

Chris Lonvick <clonvick@cisco.com> Fri, 24 January 2014 20:20 UTC

Return-Path: <clonvick@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E701A012D for <roll@ietfa.amsl.com>; Fri, 24 Jan 2014 12:20:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.036
X-Spam-Level:
X-Spam-Status: No, score=-15.036 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.535, 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 a2BN_cPMO03Q for <roll@ietfa.amsl.com>; Fri, 24 Jan 2014 12:20:20 -0800 (PST)
Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7456B1A0191 for <roll@ietf.org>; Fri, 24 Jan 2014 12:20:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5238; q=dns/txt; s=iport; t=1390594819; x=1391804419; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=Rtmx/fym38w0p8n8HNmMxMuOFN7jA3AkxJ5YqQKUviI=; b=YsvLWK6PS9P5tSOBTwb6mvEXqTO2T26OxqwmqOnNcf1/b5lVjyHmoVsR KAr/YNHpUX1dCUd5rQDH5r0GYrgSi/s9E2xlBTN8DfR9YGCUD35mG/MjF KiPdVFo8RXse7rxPy+Zbs/PEyxvdesLZ8S5RijO3CNe87AbRI8nKzvGzI E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AjQFAEnK4lKrRDoH/2dsb2JhbABagww4u3FLT4ENFnSCJQEBAQMBeQULCxQBAyMEByElEQYTCYdoAwkHDsJ7DYVWF4x2gUUBAQEJNBEHhDgEiUiKd4F8gx6LK4VBgW+BX4FQ
X-IronPort-AV: E=Sophos;i="4.95,714,1384300800"; d="scan'208";a="100563277"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-1.cisco.com with ESMTP; 24 Jan 2014 20:20:18 +0000
Received: from sjc-xdm-112 (sjc-xdm-112.cisco.com [171.71.188.44]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s0OKKCFM003931 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 24 Jan 2014 20:20:14 GMT
Date: Fri, 24 Jan 2014 12:20:12 -0800
From: Chris Lonvick <clonvick@cisco.com>
To: "Popa, Daniel" <Daniel.Popa@itron.com>
In-Reply-To: <EAD2932B-5B25-42CD-8F36-9683404641DF@itron.com>
Message-ID: <alpine.LRH.2.00.1401241218450.20137@sjc-xdm-112.cisco.com>
References: <067.78cf5d635bca77cded1fb433c133c835@trac.tools.ietf.org> <9546f1bf3d68401a8cdf837ca5528de4@BY2PR04MB807.namprd04.prod.outlook.com>, <alpine.LRH.2.00.1401240912530.20137@sjc-xdm-112.cisco.com> <EAD2932B-5B25-42CD-8F36-9683404641DF@itron.com>
User-Agent: Alpine 2.00 (LRH 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1202400444-1050087809-1390594814=:20137"
X-Mailman-Approved-At: Sat, 25 Jan 2014 08:51:51 -0800
Cc: "draft-ietf-roll-applicability-ami.all@tools.ietf.org" <draft-ietf-roll-applicability-ami.all@tools.ietf.org>, "roll@ietf.org" <roll@ietf.org>
Subject: Re: [Roll] [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jan 2014 20:20:27 -0000

Hi Daniel,

Works for me.  I was hoping that a threat model had already been written 
up - certainly you shouldn't be defining one now in this document.

Best regards,
Chris

On Fri, 24 Jan 2014, Popa, Daniel wrote:

> Thanks Chris for feedback.
>
> I believe what you advice it is more or less what we intend to do. The difference is that we do not intend to explicitly use a security threat model and show how IEEE works against it, but rather to explain how IEEE 802.15.4 and IEEE p1901.2 security mechanisms can substitute to RPL-defined security mechanisms to provide the same security services as those described in Section 19.1 of RFC 6550, while at the same time giving the system designers & implementers the same degree of freedom to trade-off complexity against security strength, in order to meet HW & cost constraints of such low power field devices.
>
> Would this be enough ?
>
> Regards,
> Daniel
>
> Sent from my iPhone
>
>> On 24 janv. 2014, at 18:32, "Chris Lonvick" <clonvick@cisco.com> wrote:
>>
>> Hi Daniel,
>>
>> Has a threat model been defined for RPL?  And do you know that the link-layer security provided by the two IEEE mechanisms will thwart the threats?  This isn't meant to be an onerous exercise.  :-)  What has been done in several WGs has been to define a simple threat model (usually taken from RFC 3552) and then describe how the security mechanisms will thwart the threats.  For example, see sections 2 and 3 in RFC 5426 (TLS for syslog).
>>
>> If you can point to the threat model for RPL then you can probably state (just once in the Security Considerations section) how the IEEE link-layer security mechanisms will address the threats so therefore the security mechanisms already contained within RPL will not be needed.
>>
>> Hope this helps,
>> Chris
>>
>>> On Tue, 14 Jan 2014, Popa, Daniel wrote:
>>>
>>> Hello all,
>>>
>>> Chris:
>>>
>>> Just to clarify: The applicability statement for AMI network focuses on use of RPL (+ 6LowPAN/IPv6) over standard IEEE wireless and PLC link-layer technologies (i.e., IEEE Std 802.15.4g/4e and IEEE Std P1901.2, respectively). Each of these standards is coming with a link-layer security specification.
>>>
>>> Following you recommendation: we can add a new section - "Security Considerations" - to the section where we describe the link-layer security features (i.e., to the Section 9.2.3 called "Security features provided by the MAC sub-layer"). Alternatively, we can keep the Section 9.2.3 as it is and in the content that will be provided we describe how the link-layer security features will meet the requirements of the RPL security services.  Which of these approaches will better answer your request?
>>>
>>> Would such clarifications meet your expectations?
>>>
>>> Regards,
>>> Daniel
>>>
>>> -----Message d'origine-----
>>> De : roll issue tracker [mailto:trac+roll@grenache.tools.ietf.org]
>>> Envoyé : mardi 17 décembre 2013 06:51
>>> À : draft-ietf-roll-applicability-ami.all@tools.ietf.org; mariainesrobles@gmail.com
>>> Cc : roll@ietf.org
>>> Objet : [roll] #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used
>>>
>>> #136: - draft-ietf-roll-applicability-ami - Add a section of the Security Considerations for each instance where the RPL security mechanism are not to be used
>>>
>>> Source: http://www.ietf.org/mail-archive/web/secdir/current/msg04477.html
>>>
>>>
>>> From: Chris Lonvick <clonvick at cisco.com>
>>> Date: Fri, 13 Dec 2013 11:41:54 -0800 (PST)
>>>
>>>
>>>
>>> “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.”
>>>
>>> --
>>> -------------------------------------+----------------------------------
>>> -------------------------------------+---
>>> Reporter:                           |      Owner:  draft-ietf-roll-
>>> mariainesrobles@gmail.com          |  applicability-
>>>    Type:  defect                   |  ami.all@tools.ietf.org
>>> Priority:  major                    |     Status:  new
>>> Component:  applicability-ami        |  Milestone:
>>> Severity:  Active WG Document       |    Version:
>>>                                    |   Keywords:
>>> -------------------------------------+----------------------------------
>>> -------------------------------------+---
>>>
>>> Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/136>
>>> roll <http://tools.ietf.org/wg/roll/>
>>>
>