Subject: [secdir] Fwd: FW: draft-ietf-roll-applicability-template

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Jan 2013 00:31:00 +0000

Hi all,

The roll folks are looking for a review of this I-D.
If someone feels the love, can you let Tero know and
he'll capture that. If nobody does, then Tero, can
you pick whoever's next in the rotation.

Thanks,
S.

-------- Original Message --------
Subject: FW: draft-ietf-roll-applicability-template
Date: Tue, 29 Jan 2013 17:59:36 -0000
From: Adrian Farrel <[email-masked]>
Reply-To: <[email-masked]>
To: <[email-masked]>
CC: <[email-masked]>, <[email-masked]>

Copying Sean in just in case he is inclined to say something.

A

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael
> Richardson
> Sent: 27 January 2013 20:46
> To: [email-masked]
> Cc: Adrian Farrel; [email-masked]
> Subject: draft-ietf-roll-applicability-template
> 
> 
> I'm still looking for SEC Directorate review of the ROLL applicability
> template.
> 
> The idea is to make sure that security question will get addressed
> earlier in the process, rather than at SEC Directorate review time.
> 
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [
> 
>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 30 Jan 2013 10:00:08 +0000

> you pick whoever's next in the rotation.

Do you mean https://datatracker.ietf.org/doc/draft-richardson-roll-applicability-template/?include_text=1?
There doesn't appear to be a draft-ietf-

If so, there's no info in it to base a security review on.

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Jan 2013 10:30:01 +0000

Ah, apologies for even asking if its that non-draft.
(I didn't look;-)

I'll go back and beat 'em up if so.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Jan 2013 10:35:32 +0000

> I'll go back and beat 'em up if so.

Sorry again. Now I remember.

So this is really a template. Their plan is that they'll
have a bunch of other RPL applicability statement
drafts that say how to use the protocol in building
control, etc. Each will use this template.

Their question to us is what other things should those
drafts be required (by this template) to say about
security. So I guess we might say e.g. automated key
management (BCP 107) needs to be well-defined and
mandatory to implement.

S.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 30 Jan 2013 10:44:39 +0000

> management (BCP 107) needs to be well-defined and

I got that, but it seems impossible to answer without knowing a lot
more about ROLL than that doc says. Or RPL, whatever that is (not
defined in the doc).

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Jan 2013 11:03:35 +0000

> more about ROLL than that doc says. Or RPL, whatever that is (not

True enough. Don't volunteer so:-)

If we have someone who knows RPL, (and its a bit of a monster)
it'd make more sense for them to take this.

The background here is that I inherited a DISCUSS from
Tim on a RPL document to the effect that they had
no automated key management (AKM) defined which BCP107
says they need. They argued (fairly I think) that the
method for AKM that you'd make mandatory to implement
might well differ for different applications using RPL
but eventually that draft ended up back in the WG.

So now they're trying to make sure they don't hit that
problem again via this template for applicability
statements.

So I hope any review we do says at least: "Add a
requirement that applicability statements MUST specify
an AKM method as MTI."

Given how complex RPL is though, there could well be
more to say, hence their request.

S.