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

From: JP Vasseur <[email-masked]>
Date: Thu, 2 Dec 2010 11:58:36 +0100

Hi

Do you want to look at the comments and get back to Adrian ?

Thanks.

JP.

On Nov 23, 2010, at 11:38 AM, Adrian Farrel wrote:

> 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.
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Tsao, Tzeta" <[email-masked]>
Date: Thu, 2 Dec 2010 09:52:02 -0500

Hi,

The authors appreciate the input and will put out a revision as soon as
possible.

Thanks,
Tzeta

-----Original Message-----
From: JP Vasseur [mailto:[email-masked]] 
Sent: Thursday, December 02, 2010 5:59 AM
To: Tsao, Tzeta
Cc: Adrian Farrel; [email-masked];
ROLL WG
Subject: Re: [Roll] AD review of draft-ietf-roll-security-framework

Hi

Thanks.

JP.

---

From: JP Vasseur <[email-masked]>
Date: Thu, 2 Dec 2010 15:54:51 +0100

Thanks Tzeta and all co-authors.

JP.

---

From: "Tsao, Tzeta" <[email-masked]>
Date: Fri, 10 Dec 2010 14:19:41 -0500

WG,

We have posted draft-ietf-roll-security-framework-03, which should
be available from the repository shortly. The main changes are to
address AD's comments. New texts are added to better explain the
integrity principle under consideration, as well as some discussions
on key management.

Thanks,
Tzeta

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Tuesday, November 23, 2010 5:38 AM
To: [email-masked]
Cc: [email-masked]
Subject: AD review of draft-ietf-roll-security-framework

Hi,

Don't panic!

Thanks for the work,
Adrian

---

---

---

---

Section 3.2

s/on/on a/

---

Section 3.2

   Integrity

---

Section 3.2

         In addition,

---

Section 3.2

"those" what?

Suggest...

---

Section 3.2

Non-repudiation

That analysis is fine.

---

Section 3.3

"trade study"?

---

Section 3.3

s/Lln/LLN/

---

Section 3.3

---