Subject: [Roll] Roll Digest, Vol 48, Issue 1 - roll-rpl-industrial-applicability

From: "amit" <[email-masked]>
Date: Tue, 17 Jan 2012 16:16:49 +0200

Regarding your security comment, don’t you think that the basic assumption
of the RPL draft that the devices are trusted, is problematic. Moreover,
roll-rpl-industrial-applicability consider the case that other layers will
take care about the security (section 5.3), however, counting on upper layer
can't solve security problems of the RPL parameters and the link layer can't
be trusted when node can be compromise. 
I know that compromise is out of the scope but maybe we need to start
thinking about those cases.

-----הודעה מקורית-----
מאת: [email-masked] [mailto:[email-masked]] בשם
[email-masked]
נשלח: יום ב 02 ינואר 2012 22:00
אל: [email-masked]
נושא: Roll Digest, Vol 48, Issue 1

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/roll

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or
Plain Text Digests?" to MIME.  You can set this option globally for all the
list digests you receive at this point.

Send Roll mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/roll
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific than
"Re: Contents of Roll digest..."

Today's Topics:

   1. roll-rpl-industrial-applicability (Michael Richardson)

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

Message: 1
Date: Mon, 02 Jan 2012 11:16:06 -0500
From: Michael Richardson <[email-masked]>
To: IETF ROLL <[email-masked]>
Subject: [Roll] roll-rpl-industrial-applicability
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

Some comments on draft-phinney-roll-rpl-industrial-applicability-00.
I promised myself during the last IETF that I'd read it, and new year's day
was a good to do that.

pg4:
>   A field device that belongs to an instance uses the OF to determine
>   which DODAG and which Version of that DODAG the device should join.

I did not think that the OF would tell us which Version of a DODAG to use.
The version simply increments... I guess if the new values from the new
version do not satisfy the OF, one could stay with the previously calculated
parents, etc.

I was very pleased to read section 3.1.  Deployment scenarii.
In it, 6 scenarios are described:
     P1: Construction or major modification phase
     P2: Planned startup phase
     P3: Normal operation phase
     P4: Planned shutdown phase
     P5: Plant decommissioning phase.
     P6: Post-emergency recovery and repair phase.

The analysis that follows concerns me:

>   The deployment scenarios for wireless LLN devices may be different in
>   each of these phases.  In particular, during the Construction or
>   major modification phase (P1), LLN devices may be installed months
>   before the intended LLN can become usefully operational (because
>   needed routers and infrastructure devices are not yet installed or
>   active), and there are likely to be many personnel in whom the plant
>   owner/operator has only limited trust, such as subcontractors and
>   others in the plant area who have undergone only a cursory background
>   investigation (if any at all).  In general, during this phase, plant

I very much wish that this had appeared in RFC5673 as input into the
security mechanism.  I think that a major limitation in the current
documents in the security area here.  I could go on awhile about how I think
things should work to solve this; I didn't do that before, because I didn't
think that there was real requirements for a system a flexible
as I envision.   

NOTE: this is not a fault of this document, it's a failure of our
      requirements process for security.

draft-phinney-roll-rpl-industrial-applicability-00 recaps too many things,
and I find is way too chatty.  I expect an applicability statement to be
more to the point.  This relates to section 3 mostly, I think.

The chart in section 3.3:

+---------------------+------------------------------------------------+
|   Phase \  Class    |   0       1       2       3       4       5    |
+=====================+================================================+
|   Construction      |                   X       X       X       X    |
+---------------------+------------------------------------------------+
|   Planned startup   |                   X       X       X       X    |
+---------------------+------------------------------------------------+
|   Normal operation  |                           ?       ?       ?    |
+---------------------+------------------------------------------------+
|   Planned shutdown  |                   X       X       X       X    |
+---------------------+------------------------------------------------+
|Plant decommissioning|                   X       X       X       X    |
+---------------------+------------------------------------------------+
| Recovery and repair |   X       X       X       X       X       X    |
+---------------------+------------------------------------------------+

also is of concern. What it says is that RPL can't be used for 

      *  Class 0: Emergency action - Always a critical function
      *  Class 1: Closed loop regulatory control - Often a critical
         function
      *  Class 2: Closed loop supervisory control - Usually non-critical
         function

during any phase, except during repair.  And, that we don't even know if it
can be used for Normal operation!  That's hardly an huge endorsement!

Thank you kindly for this -00 document.  I realize that section 5 is where
the meat will go, and I look forward to some clear recommendations here.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls
[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device
driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL:
<http://www.ietf.org/mail-archive/web/roll/attachments/20120102/22827853/att
achment.sig>

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

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

End of Roll Digest, Vol 48, Issue 1
***********************************

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 17 Jan 2012 16:40:30 +0100

Hello Amit

In practice, as of today, the main standards in the industrial space rely on L2 security that is set up during a join process. 
ISA100.11a that also has our traditional upper layers uses the same crypto at L2 and L4 but has no L3 security.  This enables to reuse hardware support that is available in common chipsets.
The RPL draft provides for securing its own when L2 security is not in place but I do not see that in use in industrial space any time soon.

Was that your questions?

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of amit
Sent: mardi 17 janvier 2012 15:17
To: [email-masked]
Subject: [Roll] Roll Digest, Vol 48,Issue 1 - roll-rpl-industrial-applicability

Regarding your security comment, don’t you think that the basic assumption of the RPL draft that the devices are trusted, is problematic. Moreover, roll-rpl-industrial-applicability consider the case that other layers will take care about the security (section 5.3), however, counting on upper layer can't solve security problems of the RPL parameters and the link layer can't be trusted when node can be compromise. 
I know that compromise is out of the scope but maybe we need to start thinking about those cases.

-----הודעה מקורית-----
מאת: [email-masked] [mailto:[email-masked]] בשם [email-masked]
נשלח: יום ב 02 ינואר 2012 22:00
אל: [email-masked]
נושא: Roll Digest, Vol 48, Issue 1

If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription.  To do so, go to 

Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME.  You can set this option globally for all the list digests you receive at this point.

Today's Topics:

Message: 1

Some comments on draft-phinney-roll-rpl-industrial-applicability-00.
I promised myself during the last IETF that I'd read it, and new year's day was a good to do that.

I did not think that the OF would tell us which Version of a DODAG to use.
The version simply increments... I guess if the new values from the new version do not satisfy the OF, one could stay with the previously calculated parents, etc.

>   investigation (if any at all).  In general, during this phase, plant

I very much wish that this had appeared in RFC5673 as input into the security mechanism.  I think that a major limitation in the current documents in the security area here.  I could go on awhile about how I think things should work to solve this; I didn't do that before, because I didn't think that there was real requirements for a system a flexible
as I envision.   

draft-phinney-roll-rpl-industrial-applicability-00 recaps too many things, and I find is way too chatty.  I expect an applicability statement to be more to the point.  This relates to section 3 mostly, I think.

during any phase, except during repair.  And, that we don't even know if it can be used for Normal operation!  That's hardly an huge endorsement!

Thank you kindly for this -00 document.  I realize that section 5 is where the meat will go, and I look forward to some clear recommendations here.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls
[
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net
architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Jan 2012 10:49:48 -0500

"security comment' extracted from original email below.

What I see is that the LLN (I say this because it might be more than
RPL) needs to be able to provide a variety of security services over the
lifetime of the LLN.

In particular it seems to me that the LLN needs to provide a relatively
trivial security system during initial building of the plant.
By this, I mean, very trivial to configure, perhaps involving well
known "secret"s, not necessarily weak encryption.  In fact, you want to
do all the testing with the full key strength so that if there are
cryptographic related performance problems they show up immediately.

You disclose nothing useful to the untrusted contractors who install
things as they configure the system using the maint/field password. (To
recall the situation of VAX/VMS in the 1980s)

Then, the plant has to be "upgraded" to full security, and this has to
be done easily by internal personnel.  This means that the upgrade has
to be performed using standard protocols, physical interfaces and user
interfaces!    There is a risk, of course, that the plant will go into
production with the factory default passwords.

I want to further point out that in many places, some part of the plant
is ALWAYS under going maintenance, and so the LLN has to be able to deal
with multiple security simultaenous security regimes.

Can the current Layer-2 solutions deal with this?
I know that 802.1x/EAP protocols support it, but in the field, it's
either unimplemented, or too hard to support.   Can Zigbee's security model?

What we need to do, I think, is to realize that we have to have some
coupling of layer-2 and layer-3 security services.  Too much is bad, but
we need at least channel binding.

>>>>> "amit" == amit  <[email-masked]> writes:
    amit> Regarding your security comment, don't you think that the

    amit> basic assumption of the RPL draft that the devices are
    amit> trusted, is problematic. Moreover,
    amit> roll-rpl-industrial-applicability consider the case that other
    amit> layers will take care about the security (section 5.3),
    amit> however, counting on upper layer can't solve security problems
    amit> of the RPL parameters and the link layer can't be trusted when
    amit> node can be compromise. I know that compromise is out of the
    amit> scope but maybe we need to start thinking about those cases.

    mcr> The analysis that follows concerns me:

    mcr> The deployment scenarios for wireless LLN devices may be
    mcr> different in each of these phases.  In particular, during the
    mcr> Construction or major modification phase (P1), LLN devices may be
    mcr> installed months before the intended LLN can become usefully
    mcr> operational (because needed routers and infrastructure devices
    mcr> are not yet installed or active), and there are likely to be many
    mcr> personnel in whom the plant owner/operator has only limited
    mcr> trust, such as subcontractors and others in the plant area who
    mcr> have undergone only a cursory background investigation (if any at
    mcr> all).  In general, during this phase, plant

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Jan 2012 12:36:52 -0500

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> Was that your questions?

Amit was responding to my email, wherein I noted that our security
features do not in fact meet the expectations of the industrial
applicability statement.  Nor, as far as I can see, do layer-2
mechanisms help at all, as they provide no way to limit trust to
subcontractors.  

They are boolean (you either have the network key, or you do not).

    >> The deployment scenarios for wireless LLN devices may be
    >> different in each of these phases.  In particular, during the
    >> Construction or major modification phase (P1), LLN devices may be
    >> installed months before the intended LLN can become usefully
    >> operational (because needed routers and infrastructure devices
    >> are not yet installed or active), and there are likely to be many
    >> personnel in whom the plant owner/operator has only limited
    >> trust, such as subcontractors and others in the plant area who
    >> have undergone only a cursory background investigation (if any at
    >> all).  In general, during this phase, plant

    > I very much wish that this had appeared in RFC5673 as input
    > into the security mechanism.  I think that a major
    > limitation in the current documents in the security area
    > here.