Subject: [Roll] an initial review of security-framework-00

From: Tzeta Tsao <[email-masked]>
Date: Sun, 18 Apr 2010 21:44:29 -0700 (PDT)

Hi Michael,

Thanks for your feedback.

Indeed, we did intend to put into perspective the cross-cutting nature of security in the context of a generic ROLL protocol. Still, for example, the transition of Section 4 to Section 5 could be improved.

But more importantly, I would also want to make sure that I understand you correctly. When you say you were expecting to see "an analysis of RPL", did you mean that the security framework draft should be specifically addressed to RPL?

Thanks,
Tzeta

----- Original Message ----
From: Michael Richardson <[email-masked]>
To: IETF ROLL <[email-masked]>
Sent: Sun, April 18, 2010 11:20:42 PM
Subject: [Roll] an initial review of security-framework-00

I read draft-ietf-roll-security-framework-00 today on the train to ARIN.
I understand that the security design team is "working", but I don't
really understand what they are working to solve yet.

I think this document was written prior to the WG adopting RPL (as a
presonal draft).  It's very generic, and non-specific to RPL.   I had a
number of very specific comments on the document, but I think that they
out-of-place, as I have in the end a few high-level comments.

It says "framework", but based upon my reading, it's more of a security
requirements --- it introduces this 'CIA' model, which is rather an
unfortunate acronum.  

Section 4 is supposed to Threats and Attacks, while section 5 covers
countermeasures.    I don't find the two sections follow this very well.

I find that this model is too focused on solutions rather than problems
as written.

What I was expecting to see was an analysis of RPL, of each of the
fundamental operations of RPL (from a network centric point of view),
with an analysis of what happens if the communication is "disclosed"
(confidentiality attack), if integrity fails, or if the message is
diverted/dropped (availability).   I would go further, and ask what
happens if the message is delayed (made to be late), or if it replayed. 

I also think that physical device compromise should be made completely
out-of-scope.  An "pwned" which is made to do malicious things is very
hard to detect, and may be comparable to a misconfigured device.  Since
a node can not tell the difference, if we need to be slightly mutually
suspicious, then we need to write that analysis, and not worry about
things like how to harden the device itself.  Rather, we have to worry,
in the design of the cryptography and protocol, to minimize how much
damage can occur when a device is misconfigured-and-or-pwned.

section 5.3.2) says:

       "Finally, if communication is sufficiently secured, only trusted
       nodes can receive and forward traffic which also lowers the risk
       of an overload attack. "

While I'm a major fan of layer-3 security, it seems that we should
clearly understand the use cases that forbid the above policy.  It seems
to be the best policy for many situations.  

When we understand the use cases for which the above policy is too
restrictive, then I think we can build the right security mechanisms.

I believe that the Home Automation scenario is likely where to crack
this nut.   I expect, when I invite people in to my home, to give them
access (from their personal devices) to be able access my network.  

(At a higher-level, I will authorize them to do things like turn on/off
lights, order pizza, or look at my family photos... but that's higher
level)

At it's most simple, if you visit my automated home, you need to be able
to get past the layer-2 security easily, and you need to be able to
become a leaf on my network.

So, from a security point of view, if we can build layer-3 security that
does not permit some nodes to become core nodes, then we may have solved
95% of use cases.

I have a number of comments about diversity of routes, but I think they
are too specific at this time.

What happens to this document now?

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

            

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