Subject: [Roll] security solutions for ROLL

From: Michael Richardson <[email-masked]>
Date: Thu, 23 Feb 2012 16:51:29 -0500

1) there is an Security AD DISCUSS from Stephen Farrell/Tim Polk.
   http://datatracker.ietf.org/doc/draft-ietf-roll-security-framework/ballot/#stephen-farrell
   It has been there for 9 months, and we need to act on it, because
   this DISCUSS is keeping draft-ietf-roll-of0-20 from advancing,
   and that will keep draft-ietf-roll-rpl-19 from being published.

So to be clear, this chain of dependancies/references means that while
rpl-19 has been done for some time, it won't get published until we do
something.

Stephen Farrell will lift his DISCUSS on this and let us proceed if he
sees some credible plan to get useable security into the layer-3 of
RPL.  

For a lot of you, you have assumed security at layer-2 is enough, and
you may never care about this mechanism, but I still need your
participation here.  

2) We will need to provide, in the draft-ietf-roll-security-framework,
   a clear set of security related *questions* that each applicability
   statement will need to answer.  In esssence, this is a template
   that needs to be filled out.

3) A proposal for moving forward is to adopt/adapt MIKEY
   (RFC3830) for our uses.
   This has been proposed in:
      draft-alexander-roll-mikey-lln-key-mgmt 

   This draft needs to be resubmitted for the WG to consider it.
   (A rumour is that it can be found at: 
     http://tools.ietf.org/id/draft-alexander-roll-mikey-lln-key-mgmt-02.txt
   )

  The WG is open to other proposals, but they need to come in quickly.
  We do not need to complete the work, but we do need to know what work
we need to do, and we need to update our milestones to include that work
in order that we can progress.

-- 
]       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: Levente Buttyan <[email-masked]>
Date: Fri, 24 Feb 2012 08:32:30 +0100

Dear Michael,

Our work on version number and rank authentication addresses some
layer-3 security issues that is not addressed by layer-2 security
mechanisms. In particular, layer-2 protection does not prevent a
malfunctioning or misbehaving (compromised) node from initiating the
reconstruction of the DODAG with itself as the root. Also manipulating
the rank value in DIO messages may result in the distortion of the
topolgy, i.e., a misbehaving node can appear to be closer to the root
than it really is. The mechanisms that we proposed try to prevent these
misdeeds. They are also lightweight, using hash functions and symmetric
key crypto as much as possible.

Our draft is available at:
http://tools.ietf.org/html/draft-dvir-roll-security-authentication-01

We also have an implementation (on both TinyOS and Linux) of RPL and the
version number authentication mechanisms that we plan to make available
soon.

My colleague, Amit Dvir will be in Paris for the IETF meeting to present
this work and to discuss it further.

Best regards,
Levente Buttyan

2012.02.23. 22:51 keltezéssel, Michael Richardson írta:
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

-- 
Dr. Levente Buttyán
Laboratory of Cryptography and System Security (CrySyS)
Department of Telecommunications
Budapest University of Technology and Economics (BME)
URL: http://www.crysys.hu/

---

From: "Tsao, Tzeta" <[email-masked]>
Date: Fri, 24 Feb 2012 10:10:48 -0500

Michael, WG:

My understanding of the DISCUSS on the security framework draft is that
it seeks to address the perceived lack of key management for RPL.
However, the second item in your post seems to go beyond that; is it a
set of questions to justify the use or non-use of RPL security, for
example? Please clarify.

Thanks,
Tzeta

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Michael Richardson
> Sent: Thursday, February 23, 2012 4:51 PM
> To: [email-masked]
> Subject: [Roll] security solutions for ROLL
> 
> 
> we need to do, and we need to update our milestones to include that
> work in order that we can progress.
> 
> --
> ] [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: Fri, 24 Feb 2012 15:06:43 -0500

>>>>> "Levente" == Levente Buttyan <[email-masked]> writes:
    Levente> Our work on version number and rank authentication
    Levente> addresses some layer-3 security issues that is not
    Levente> addressed by layer-2 security mechanisms. In particular,
    Levente> layer-2 protection does not prevent a malfunctioning or
    Levente> misbehaving (compromised) node from initiating the
    Levente> reconstruction of the DODAG with itself as the root. Also
    Levente> manipulating the rank value in DIO messages may result in
    Levente> the distortion of the topolgy, i.e., a misbehaving node can
    Levente> appear to be closer to the root than it really is. The
    Levente> mechanisms that we proposed try to prevent these
    Levente> misdeeds. They are also lightweight, using hash functions
    Levente> and symmetric key crypto as much as possible.

I agree that your proposals are rather usefu additions, and I would like
to see them adopted by the WG.

However, the concern that the ADs had is essentially about how would
one bootstrap layer-3 security?  Assume that we had your proposal in
place, we still require an initial set of symmetric trust relation to
use them.

The issue on the table is: how do we get that?

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Feb 2012 16:13:58 -0500

>>>>> "Tzeta" == Tzeta Tsao <Tsao> writes:
    Tzeta> My understanding of the DISCUSS on the security framework
    Tzeta> draft is that it seeks to address the perceived lack of key
    Tzeta> management for RPL.  However, the second item in your post
    Tzeta> seems to go beyond that; is it a set of questions to justify
    Tzeta> the use or non-use of RPL security, for example? Please
    Tzeta> clarify.

I agree that point #2 is almost a non-sequitar.
My appologies for this, I should have seperated it out.

It came out of a discussion thread which I think was not well archived.
(In fact, due to top-posting, I could barely understand it)

What I did was share three things with the ADs involved to confirm my
understanding prior to posting.

I think it is up to the writers of the applicability statement to decide
if they want to recommend layer-2 or layer-3 security for an LLN
deployment in their environment that includes RPL.  
If they recommend layer-2, then it is, "not our problem".

If they recommend layer-3 or do not make a clear recommendation, then
there needs to be a clear set of questions.  These are questions
relating to the knobs which are presently available in rpl-19, not to
things that we might invent to do key management.  

We are making the same request in these documents for things like
MinHopRankInc, Storing Mode, etc.

draft-ietf-roll-security-framework has essentially setup a list of
requirements, which rpl-19 has tried to satisfy with some knobs.

For instance, should an industrial network operate with Authentication
Enabled?  Yes/No.
Should they use KIM 0, 1 or 2?  If so, what LVL?

draft-ietf-roll-security-framework should be identifying why we have
those 3 x 4 choices.  (i.e. what were the security requirements that
made us decide we needed MAC-32/ENC-MAC-32 and 64-bit versions)

    >> -----Original Message----- From: [email-masked]
    >> [mailto:[email-masked]] On Behalf
    Tzeta> Of
    >> Michael Richardson Sent: Thursday, February 23, 2012 4:51 PM To:
    >> [email-masked] Subject: [Roll] security solutions for ROLL
    >> 
    >> 
    >> http://datatracker.ietf.org/doc/draft-ietf-roll-security-
    >> framework/ballot/#stephen-farrell It has been there for 9 months,
    >> and we need to act on it, because this DISCUSS is keeping
    >> draft-ietf-roll-of0-20 from advancing, and that will keep
    >> draft-ietf-roll-rpl-19 from being published.
    >> 
    >> So to be clear, this chain of dependancies/references means that
    >> while rpl-19 has been done for some time, it won't get published
    >> until we do something.
    >> 
    >> Stephen Farrell will lift his DISCUSS on this and let us proceed
    >> if he sees some credible plan to get useable security into the
    >> layer-3 of RPL.
    >> 
    >> For a lot of you, you have assumed security at layer-2 is enough,
    >> and you may never care about this mechanism, but I still need
    >> your participation here.
    >> 
    >> 2) We will need to provide, in the
    >> draft-ietf-roll-security-framework, a clear set of security
    >> related *questions* that each applicability statement will need
    >> to answer.  In esssence, this is a template that needs to be
    >> filled out.
    >> 
    >> (RFC3830) for our uses.  This has been proposed in:
    >> This draft needs to be resubmitted for the WG to consider it.  (A
    >> rumour is that it can be found at:
    >> http://tools.ietf.org/id/draft-alexander-roll-mikey-lln-key-mgmt-
    >> 02.txt )
    >> 
    >> The WG is open to other proposals, but they need to come in
    >> quickly.  We do not need to complete the work, but we do need to
    >> know what
    Tzeta> work
    >> we need to do, and we need to update our milestones to include
    >> that work in order that we can progress.
    >> 
    >> --
    >> ] 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/
    Tzeta> |device
    >> driver[ Kyoto Plus: watch the video
    >> <http://www.youtube.com/watch?v=kzx1ycLXQSE> then sign the
    >> petition.