Re: [Roll] security solutions for ROLL

[Michael Richardson <[e-mail]>]

>>>>> "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: [e-mail]
    >> [mailto:[e-mail]] On Behalf
    Tzeta> Of
    >> Michael Richardson Sent: Thursday, February 23, 2012 4:51 PM To:
    >> [e-mail] Subject: [Roll] security solutions for ROLL
    >> 
    >> 
    >> 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
    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[ ] [e-mail]
    >> 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.