Subject: [Roll] AD review of draft-ietf-roll-security-framework

From: Adrian Farrel <[email-masked]>
Date: Tue, 23 Nov 2010 10:38:16 +0000

Hi,

I have performed an AD review of your draft.

Don't panic!

I review all drafts that I am responsible for before putting them
forward for IETF last call. The main objective is to catch nits and
minor issues that would show up during the last call or in IESG 
review. The intention is to help polish your document and make sure
it is clean and shiny so that other reviewers will stick to the
technical details.

Thanks for a very thorough survey of the landscape, and a well written
document.

Most of my comments are pretty trivial, but a couple have more meat
on them and I'd like to see a quick respin of the document before I
issue the IETF last call. As soon as I see a new revision posted,
I'll set the ball in motion.

Of course, all of my issues are up for discussion.

Thanks for the work,
Adrian

---

idnits gives two warnings about references:

  == Unused Reference: 'I-D.ietf-6man-rpl-option' is defined on lines
     1786, but no explicit reference was found in the text

  == Outdated reference: A later version (-14) exists of
     draft-ietf-roll-rpl-11

---

I think that Section 1 uses [I-D.ietf-roll-terminology] as a normative
reference. You may want to look at this to decide whether you can avoid
or dilute the reference so that you are not blocked in the RFC Editor 
Queue.

---

The RFC Editor usually likes the first section in the document to be
the Introduction. I think you can safely swap the Terminology section
with the Introduction.

---

Section 3.2

         Because LLNs are most commonly found on publicly accessible
         shared medium, e.g., air or wiring in a building, and sometimes

s/on/on a/

---

Section 3.2

   Integrity
         Integrity, as a security principle, entails the protection of
         routing information and routing neighbor maintenance exchanges,
         as well as derived information maintained in the database, from
         misuse or unauthorized and improper modification.

I'm not comfortable with "misuse" in the context of integrity. The term
suggests to me that the information might be used for illicit purposes
which I would think ties in with "confidentiality" not "integrity". Am I
missing something?

---

Section 3.2

         In addition,
         integrity also requires the authenticity of claimed identity in
         the origin and destination of a message, access and removal of
         data, execution of the routing process, and use of computing
         and energy resources.

I'm curious that you tie authenticity to the *message* source and 
destination rather than to the *information*. This has been a debate in
routing security for some time. Consider an IGP where one could
authenticate the message exchanges between protocol peers, or one could
authenticate the link state information that is being distributed.
Clearly there are implications for the solution, and the chain-of-trust
model of the former may achieve the latter. However, I think that the
asset is the information not the message, and it is the asset that must
be authenticated.

---

Section 3.2

   It is noted that, besides those captured in the CIA model, assurance

"those" what?

Suggest...

   It is noted that, besides those security issues captured in the CIA
   model, assurance

---

Section 3.2

Non-repudiation

Reading this section, it seems to me that you have identified non-
repudiation as a viable threat to ROLL. You have also recognised that 
the traditional mechanisms for discovering it are hard or impossible to
apply in a LLN. 

That analysis is fine.

But then you go on to say "it is hard, so we won't talk about it"! This
doesn't seem to be right. At the very least you should provide an
analysis of the risks and impact of non-repudiation in ROLL. You can
then also quantify the issues with applying traditional techniques, and
this might motivate people to derive new techniques (or to determine
that it is not a significant problem in ROLL).

---

Section 3.3

         As a consequence of these constraints, there is an even more
         critical need than usual for a careful trade study on which and

"trade study"?
Do you mean "study of trade-offs"? Or just "study"?

---

Section 3.3

   Highly directional traffic
         Some types of LLNs see a high percentage of their total traffic
         traverse between the nodes and the Lln Border Routers (LBRs)

s/Lln/LLN/

---

Section 3.3

I'm not sure, but I think you should add some emphasis on the ease with
which nodes can attach to some LLNs (especially wireless ones). To some
extent this might be covered by the "ad hoc" elements in
   Autonomous operations
and by the bullet item
   Unattended locations and limited physical security
but I think you should draw this out specifically as it is one of the
greater security issues that I have heard voiced.

---

I think that the discussion of key management is a bit weak. The issue
is identified in Sections 3.3 and 3,4 as something that can be made
more complicated in the LLN environment, but then very little is made
of the topic in the document.

I think you should have a look at RFC 4107, which should probably one of 
your references, and then see whether there is anything you can add,
possibly to Sections 6 and 7.