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

From: "Popa, Daniel" <[email-masked]>
Date: Tue, 14 Jan 2014 14:48:44 +0000

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:[email-masked]] 
Envoyé : mardi 17 décembre 2013 06:51
À : [email-masked]; [email-masked]
Cc : [email-masked]
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-
  [email-masked]          |  applicability-
     Type:  defect                   |  [email-masked]
 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/>

---

From: "roll issue tracker" <[email-masked]>
Date: Tue, 14 Jan 2014 15:01:16 -0000

#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

Comment (by [email-masked]):

 Thread: http://www.ietf.org/mail-archive/web/roll/current/msg08423.html

 From: "Popa, Daniel" <Daniel.Popa at itron.com>
 Date: Tue, 14 Jan 2014 14:48:44 +0000

 “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? “

-- 
-------------------------------------+-------------------------------------
 Keywords:                           |  Resolution:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/136#comment:1>
roll <http://tools.ietf.org/wg/roll/>

---

From: "Popa, Daniel" <[email-masked]>
Date: Fri, 24 Jan 2014 18:10:36 +0000

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" <[email-masked]> 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:
>>

---

From: "roll issue tracker" <[email-masked]>
Date: Sat, 25 Jan 2014 14:52:05 -0000

Thread: http://www.ietf.org/mail-archive/web/roll/current/msg08437.html

 Date: Fri, 24 Jan 2014, at 18:32, "Chris Lonvick" <clonvick at cisco.com>
 wrote

 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.

 ----------------------
 From: "Popa, Daniel" <Daniel.Popa at itron.com>
 Date: Fri, 24 Jan 2014 18:10:36 +0000

 “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 ?

 -------------------------------------

 Date: Fri, 24 Jan 2014, "Chris Lonvick" <clonvick at cisco.com> wrote

 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.

Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/136#comment:2>
roll <http://tools.ietf.org/wg/roll/>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 25 Jan 2014 10:06:25 -0500

Chris Lonvick <[email-masked]> wrote:
    > 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).

    > mechanisms already contained within RPL will not be needed.

draft-ietf-roll-security-threats.

--
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 24 Jan 2014 09:32:41 -0800 (PST)

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).

Hope this helps,
Chris

On Tue, 14 Jan 2014, Popa, Daniel wrote:

> 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.
>
> 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?
>

---

From: Chris Lonvick <[email-masked]>
Date: Fri, 24 Jan 2014 12:20:12 -0800 (PST)

Hi Daniel,

Best regards,
Chris