A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)
draft-ietf-roll-security-threats-11

[Ballot comment]
I do not have a blocking issue, but I'll note that issues from the earlier Gen-ART review didn't get resolved in the new version. While they are editorial, it would be much easier if raised issues were addressed, so that reviewers, ADs, or the RFC Editor do not have to track them. Approved::revised ID needed?

[Ballot comment]

Thanks for a vastly improved and, ISTM, very useful
document.

- 2nd last para of section 1: N-R is not a network
security service, I hope you properly ignored that.

- p11 2nd para: do you mean "cyclic graph" really?  I
thought RPL was all DAGs? Maybe a typo?

- p11 2nd para: I'm not sure that I agree fully with
the conclsion. Its correct that all nodes need to be
able to act securely, but it is also true that at a
given moment in time the impact of a risk to nodes
with lower rank is higher. Could be fixed via slight
wording tweaks I guess but saying "all nodes need to
be equally secure" is not a valid conclusion.

- 7.1.1: I'm not sure authentication is really a
prerequisite here. There have been various proposals
to over time accumulate reputation for
unauthenticated endpoints, and confidentiality could
be separated from that easily.

- 7.3.4: Presumably a canary (a device that calls
home periodically) could also be used in this case.

- 8.4 is a little sad, isn't it? But for this
document, its fair. I don't actually agree that
asymmetric crypto is as expensive as indicated.  Such
arguments tend to be used in my experience long after
their sell-by dates should have passed and are
frequently found to no longer be true once tested.

- I tend to agree that the GEN-ART review's nits
should be fixed. There are still a number of typos
and other things to fix.

[Ballot comment]
The following text could be more clearly stated:
"""
        Applied to routing, non-repudiation is not an
        issue because it does not apply to routing protocols, which are
        machine-to-machine protocols.
"""

It seems like it would be helpful to clarify that this is because the routing protocols themselves do not have a notion of repudiation, so the security mechanism for routing protocols doesn't need to put a control on repudiation.  Suggested text:
"""
Routing protocols typically do not have a notion of repudiation, so non-repudiation services are not required.
"""

[Ballot comment]
Thank you very much for factoring in all of the changes suggested in the SecDir review.
http://www.ietf.org/mail-archive/web/secdir/current/msg03712.html
http://www.ietf.org/mail-archive/web/secdir/current/msg03715.html
http://www.ietf.org/mail-archive/web/secdir/current/msg03719.html
http://www.ietf.org/mail-archive/web/secdir/current/msg03848.html

Although the last message says the changes were not made, they are reflected in the current revision of the draft.  The reviews above are from last year and the comments were mostly addressed.

I just have a few non-blocking comments/questions.

Section 4.3:

What's a sleepy node?  This came up in the SecDir review too.  I see it is now defined in RFC7102, could you put in a reference?  It look slike that was the plan, but this slipped through.

Section 6.4.2
Although explanations are provided in the referenced Karlof2003, short descriptions of each attack type would be helpful to include in this section as well.  I see they are described a little in later sections, but it would be better on first use.

It seems that Steve Kent's review was helpful in shaping this version of the draft, shouldn't he be acknowledged?

[Ballot comment]
I think this is a nice improvement over the -01 version that we reviewed a year and a half ago.  Thanks for all the work on the document.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-roll-security-threats-09, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Security Threat Analysis for Routing Protocol for Low-power and lossy networks (RPL)) to Informational RFC

The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'A Security Threat Analysis for Routing Protocol for Low-power and
  lossy networks (RPL)'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-08-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document presents a security threat analysis for the Routing
  Protocol for Low-power and lossy networks (RPL, ROLL).  The
  development builds upon previous work on routing security and adapts
  the assessments to the issues and constraints specific to low-power
  and lossy networks.  A systematic approach is used in defining and
  evaluating the security threats.  Applicable countermeasures are
  application specific and are addressed in relevant applicability
  statements.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/ballot/


No IPR declarations have been submitted directly on this I-D.

AD Review
======
Hi authors,

I have conducted my usual AD review of your document having received a
publication request. The purpose of the review is to make sure that the
document is in the best possible shape to go through IETF last call and
IESG evaluation.

Thank you for taking the time and investing the effort on this
important document.

I find the content readable and easy to understand (thank you). I'm not
a security expert, but what you have written is clear and credible. Good
job!

There is just a small set of editorial issues that I would like you to
clean up before I run the IETF last call.

I'll put the document into "Revised I-D Needed" state and wait for you
to post a revision.

Thanks for the work,
Adrian

===-

The references are a mess as indicated by idnits and the Shepherd
write-up.

http://www.ietf.org/tools/idnits?url=http://www.ietf.org/archive/id/draft-ietf-roll-security-threats-08.txt

The point here is that you can't just include something in the
references section because you think it is a fine document or you are
friends with the author :-)  If a document is worth reading in the
context of this I-D, then there should be a mention of it somewhere
(appropriate) in the text. If there is nowhere that you find it
appropriate to mention the reference, then remove it from the references
section.

[I-D.ietf-roll-terminology] is now RFC 7102.

---

A few abbreviations are used without expansion.

I found MPLS, ESSID/PAN, CCM, PANA, EAP-TLS, DODAG.

---

Your one use of RFC 2119 language outside Section 8 is unnecessary.

  RPL uses multicast as part of it's protocol,
  and therefore mechanisms which RPL uses to secure this traffic MAY be
  applicable to MPL control traffic as well: the important part is that
  the threats are similiar.

s/it's/its/
s/MAY/might also/
s/similiar/similar/

Furthermore, while your use of 2119 in Section 8 is fine with me, it is
not in harmony with the boilerplate you have included after the
Abstract.

I suggest you move it to Section 3, and have it read...

  Although this is not a protocol specification, the key words "MUST",
  "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
  "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in RFC 2119 [RFC2119] in
  order to clarify and emphasize the guidance and directions to
  implementers and deployers of LLN nodes that utilize RPL.

---

4.3 is a helpful way to present things. I think that "Limited energy,
memory, and processing node resources" also needs to highlight the
increased susceptibility of LLN nodes to denial of service attacks since
it is not only easier o swamp such nodes, but they can be exhausted to
the extent that they are never able to function again! Such an attack
may be mounted through the routing plane (and impact both routing and
data forwarding) or through the data plane (to impact both forwarding
and routing). Thus, there is also an interdependency between the two
planes that may be tighter in LLNs than in other networks.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this
type of RFC indicated in the title page header?


i) Type of RFC Requested: Informational
ii) It is the proper type of RFC because the document describes a security threat
  analysis and not a protocol
iii) The type of RFC is indicated in the title page header


(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the
document. If not, this may be an indication that there are deficiencies in the abstract or
introduction.


The document presents a security threat analysis for the Routing Protocol for Low-
power and lossy networks (RPL, ROLL).  The development builds upon previous work
on routing security and adapts the assessments to the issues and constraints specific
to low-power and lossy networks.  A systematic approach is used in defining and
evaluating the security threats.  Applicable countermeasures are application specific
and are addressed in relevant applicability statements.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there
controversy about particular points or were there decisions where the consensus was
particularly rough?


This document is based upon draft-ietf-roll-security-framework. It was agreed to
produce a new document in line with the ROLL WG work item:

Sep 2012: Submit first draft of RPL threat analysis to the IESG to be considered as an
Informational RFC

The goal of this document is to outline threats with the expectation that applicability
statements will have to cover (i.e. mitigate or solve) these threats in some way.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of
vendors indicated their plan to implement the specification? Are there any reviewers
that merit special mention as having done a thorough review, e.g., one that resulted in
important changes or a conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the request posted?


The previous document (draft-ietf-roll-security-framework) on which this document is
based has had thorough reviews by Rene Struik, JP Vasseur, Michael Richardson and
Adrian Farrel, which ultimately contributed to the re-submission of this document.

This document has had review from Stephen Kent and Sean Turner.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?


The Document Shepherd is Robert Cragie.
The Responsible Area Director is Adrian Farrel.


(3) Briefly describe the review of this document that was performed by the Document
Shepherd. If this version of the document is not ready for publication, please explain
why the document is being forwarded to the IESG.


The Document Shepherd reviewed a previous version (06) of the document and raised some concerns which were promptly dealt with.


(4) Does the document Shepherd have any concerns about the depth or breadth of the
reviews that have been performed?


The document has not had a particularly broad review relative to other working group documents given the subject material.


(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.


As the document is regarding security threats to the RPL protocol, it is recommended
that it is reviewed by the security Area Director.


(6) Describe any specific concerns or issues that the Document Shepherd has with this
document that the Responsible Area Director and/or the IESG should be aware of?
For example, perhaps he or she is uncomfortable with certain parts of the document,
or has concerns whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to advance the document,
detail those concerns here.


The Document Shepherd has no concerns.


(7) Has each author confirmed that any and all appropriate IPR disclosures required
for full conformance with the provisions of BCP 78 and BCP 79 have already been
filed. If not, explain why?


The authors have confirmed that there are no IPR disclosures required for full
conformance with BCP 78 and BCP 79.


(8) Has an IPR disclosure been filed that references this document? If so, summarize
any WG discussion and conclusion regarding the IPR disclosures.


There are no IPR disclosures that reference the document.


(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the WG as a
whole understand and agree with it?


It represents the concurrence of a few individuals. Most of the WG has been silent on
this document.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)


No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks
are not enough; this check needs to be thorough.


idnits 2.13.00

/tmp/draft-ietf-roll-security-threats-08.txt:

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  http://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to http://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

    No issues found here.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  -- The document date (July 19, 2014) is 11 days in the past.  Is this
    intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Missing Reference: 'IS07498-2' is mentioned on line 154, but not defined

  == Unused Reference: 'RFC4107' is defined on line 1545, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4301' is defined on line 1548, but no explicit
    reference was found in the text

  == Unused Reference: 'FIPS197' is defined on line 1571, but no explicit
    reference was found in the text

  == Unused Reference: 'Huang2003' is defined on line 1575, but no explicit
    reference was found in the text

  == Unused Reference: 'I-D.alexander-roll-mikey-lln-key-mgmt' is defined on
    line 1583, but no explicit reference was found in the text

  == Unused Reference: 'IEEE1149.1' is defined on line 1600, but no explicit
    reference was found in the text

  == Unused Reference: 'Kasumi3gpp' is defined on line 1618, but no explicit
    reference was found in the text

  == Unused Reference: 'Messerges2003' is defined on line 1623, but no
    explicit reference was found in the text

  == Unused Reference: 'RFC2080' is defined on line 1644, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC2453' is defined on line 1649, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC3830' is defined on line 1655, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC4046' is defined on line 1659, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC5055' is defined on line 1672, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC5197' is defined on line 1676, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC5996' is defined on line 1700, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC6574' is defined on line 1707, but no explicit
    reference was found in the text

  == Unused Reference: 'Szcze2008' is defined on line 1728, but no explicit
    reference was found in the text

  == Unused Reference: 'Wander2005' is defined on line 1741, but no explicit
    reference was found in the text

  == Outdated reference: draft-ietf-roll-terminology has been published as
    RFC 7102

  == Outdated reference: A later version (-06) exists of
    draft-kelsey-intarea-mesh-link-establishment-05

  -- Obsolete informational reference (is this intentional?): RFC 1142
    (Obsoleted by RFC 7142)


    Summary: 0 errors (**), 0 flaws (~~), 21 warnings (==), 2 comments (--).


(12) Describe how the document meets any required formal review criteria, such as
the MIB Doctor, media type, and URI type reviews.


No formal review required.


(13) Have all references within this document been identified as either normative or
informative?


Yes.


(14) Are there normative references to documents that are not ready for advancement
or are otherwise in an unclear state? If such normative references exist, what is the
plan for their completion?


The normative reference to ZigBee IP needs fixing.


(15) Are there downward normative references references (see RFC 3967)? If so, list
these downward references to support the Area Director in the Last Call procedure.


Not applicable to an Informational RFC.


(16) Will publication of this document change the status of any existing RFCs? Are
those RFCs listed on the title page header, listed in the abstract, and discussed in the
introduction? If the RFCs are not listed in the Abstract and Introduction, explain why,
and point to the part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document, explain why the
WG considers it unnecessary.


The publication of this document will not affect the status of any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm that all
protocol extensions that the document makes are associated with the appropriate
reservations in IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has been
suggested (see RFC 5226).


There are no IANA considerations.


(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA
Experts for these new registries.


There are no new IANA registries.


(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.


There are no parts of the document written in a formal language.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this
type of RFC indicated in the title page header?


i) Type of RFC Requested: Informational
ii) It is the proper type of RFC because the document describes a security threat
  analysis and not a protocol
iii) The type of RFC is indicated in the title page header


(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the
document. If not, this may be an indication that there are deficiencies in the abstract or
introduction.


The document presents a security threat analysis for the Routing Protocol for Low-
power and lossy networks (RPL, ROLL).  The development builds upon previous work
on routing security and adapts the assessments to the issues and constraints specific
to low-power and lossy networks.  A systematic approach is used in defining and
evaluating the security threats.  Applicable countermeasures are application specific
and are addressed in relevant applicability statements.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there
controversy about particular points or were there decisions where the consensus was
particularly rough?


This document is based upon draft-ietf-roll-security-framework. It was agreed to
produce a new document in line with the ROLL WG work item:

Sep 2012: Submit first draft of RPL threat analysis to the IESG to be considered as an
Informational RFC

The goal of this document is to outline threats with the expectation that applicability
statements will have to cover (i.e. mitigate or solve) these threats in some way.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of
vendors indicated their plan to implement the specification? Are there any reviewers
that merit special mention as having done a thorough review, e.g., one that resulted in
important changes or a conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the request posted?


The previous document (draft-ietf-roll-security-framework) on which this document is
based has had thorough reviews by Rene Struik, JP Vasseur, Michael Richardson and
Adrian Farrel, which ultimately contributed to the re-submission of this document.

This document has had review from Stephen Kent and Sean Turner.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?


The Document Shepherd is Robert Cragie.
The Responsible Area Director is Adrian Farrel.


(3) Briefly describe the review of this document that was performed by the Document
Shepherd. If this version of the document is not ready for publication, please explain
why the document is being forwarded to the IESG.


The Document Shepherd has reviewed the document and has some concerns which
will be dealt with prior to publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the
reviews that have been performed?


The document has not had a particularly broad review given the subject material.


(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.


As the document is regarding security threats to the RPL protocol, it is recommended
that it is reviewed by the security Area Director.


(6) Describe any specific concerns or issues that the Document Shepherd has with this
document that the Responsible Area Director and/or the IESG should be aware of?
For example, perhaps he or she is uncomfortable with certain parts of the document,
or has concerns whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to advance the document,
detail those concerns here.


The Document Shepherd has some concerns regarding the treatment of L2 security,
which he has raised with the WG Chair.
Tickets created for the issues #150, #151, #152, #153, #154, #155 and #156


(7) Has each author confirmed that any and all appropriate IPR disclosures required
for full conformance with the provisions of BCP 78 and BCP 79 have already been
filed. If not, explain why?


The authors have confirmed that there are no IPR disclosures required for full
conformance with BCP 78 and BCP 79.


(8) Has an IPR disclosure been filed that references this document? If so, summarize
any WG discussion and conclusion regarding the IPR disclosures.


There are no IPR disclosures that reference the document.


(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the WG as a
whole understand and agree with it?


It represents the concurrence of a few individuals. Most of the WG has been silent on
this document.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If
so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)


No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks
are not enough; this check needs to be thorough.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  -- The document date (December 15, 2013) is 64 days in the past.  Is this
    intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Missing Reference: 'IS07498-2' is mentioned on line 155, but not
    defined
    'This document uses [IS07498-2] model, which includes Authenticati...'

  == Unused Reference: 'RFC4107' is defined on line 1574, but no explicit
    reference was found in the text
    '[RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographi...'

  == Unused Reference: 'RFC4301' is defined on line 1577, but no explicit
    reference was found in the text
    '[RFC4301]  Kent, S. and K. Seo, "Security Architecture for the Inter...'

  == Unused Reference: 'FIPS197' is defined on line 1600, but no explicit
    reference was found in the text
    '[FIPS197]  , "Federal Information Processing Standards Publication 1...'

  == Unused Reference: 'Huang2003' is defined on line 1604, but no explicit
    reference was found in the text
    '[Huang2003] Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. Zh...'

  == Unused Reference: 'I-D.alexander-roll-mikey-lln-key-mgmt' is defined on
    line 1612, but no explicit reference was found in the
    text
    '[I-D.alexander-roll-mikey-lln-key-mgmt] Alexander, R. and T. Tsao, "...'

  == Unused Reference: 'IEEE1149.1' is defined on line 1629, but no explicit
    reference was found in the text
    '[IEEE1149.1] , "IEEE Standard Test Access Port and Boundary Scan Arc...'

  == Unused Reference: 'Kasumi3gpp' is defined on line 1645, but no explicit
    reference was found in the text
    '[Kasumi3gpp] , "3GPP TS 35.202 Specification of the 3GPP confidentia...'

  == Unused Reference: 'Messerges2003' is defined on line 1650, but no
    explicit reference was found in the text
    '[Messerges2003] Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., S...'

  == Unused Reference: 'RFC2080' is defined on line 1671, but no explicit
    reference was found in the text
    '[RFC2080]  Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, Ja...'

  == Unused Reference: 'RFC2453' is defined on line 1676, but no explicit
    reference was found in the text
    '[RFC2453]  Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1...'

  == Unused Reference: 'RFC3830' is defined on line 1682, but no explicit
    reference was found in the text
    '[RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K....'

  == Unused Reference: 'RFC4046' is defined on line 1686, but no explicit
    reference was found in the text
    '[RFC4046]  Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "...'

  == Unused Reference: 'RFC5055' is defined on line 1699, but no explicit
    reference was found in the text
    '[RFC5055]  Freeman, T., Housley, R., Malpani, A., Cooper, D., and W....'

  == Unused Reference: 'RFC5197' is defined on line 1703, but no explicit
    reference was found in the text
    '[RFC5197]  Fries, S. and D. Ignjatic, "On the Applicability of Vario...'

  == Unused Reference: 'RFC5996' is defined on line 1727, but no explicit
    reference was found in the text
    '[RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Intern...'

  == Unused Reference: 'RFC6574' is defined on line 1734, but no explicit
    reference was found in the text
    '[RFC6574]  Tschofenig, H. and J. Arkko, "Report from the Smart Objec...'

  == Unused Reference: 'Szcze2008' is defined on line 1751, but no explicit
    reference was found in the text
    '[Szcze2008] Szczechowiak1, P., Oliveira, L., Scott, M., Collier, M.,...'

  == Unused Reference: 'Wander2005' is defined on line 1764, but no explicit
    reference was found in the text
    '[Wander2005] Wander, A., Gura, N., Eberle, H., Gupta, V., and S. Sha...'

  == Outdated reference: draft-ietf-roll-terminology has been published as
    RFC 7102

    Summary: 0 errors (**), 0 flaws (~~), 21 warnings (==), 1 comment (--).


(12) Describe how the document meets any required formal review criteria, such as
the MIB Doctor, media type, and URI type reviews.


No formal review required.


(13) Have all references within this document been identified as either normative or
informative?


Yes.


(14) Are there normative references to documents that are not ready for advancement
or are otherwise in an unclear state? If such normative references exist, what is the
plan for their completion?


The normative reference to ZigBee IP needs fixing.


(15) Are there downward normative references references (see RFC 3967)? If so, list
these downward references to support the Area Director in the Last Call procedure.


Not applicable to an Informational RFC.


(16) Will publication of this document change the status of any existing RFCs? Are
those RFCs listed on the title page header, listed in the abstract, and discussed in the
introduction? If the RFCs are not listed in the Abstract and Introduction, explain why,
and point to the part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document, explain why the
WG considers it unnecessary.


The publication of this document will not affect the status of any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm that all
protocol extensions that the document makes are associated with the appropriate
reservations in IANA registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include a detailed
specification of the initial contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has been
suggested (see RFC 5226).


There are no IANA considerations.


(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA
Experts for these new registries.


There are no new IANA registries.


(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML code,
BNF rules, MIB definitions, etc.


There are no parts of the document written in a formal language.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?


i) Type of RFC Requested: Informational
ii) It is the proper type of RFC because the document describes a security threat analysis and not a protocol
iii) The type of RFC is indicated in the title page header


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.


The document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL).  The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks.  A systematic approach is used in defining and evaluating the security threats.  Applicable countermeasures are application specific and are addressed in relevant applicability statements.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?


This document is based upon draft-ietf-roll-security-framework. It was agreed to produce a new document in line with the ROLL WG work item:

Sep 2012: Submit first draft of RPL threat analysis to the IESG to be considered as an Informational RFC

The goal of this document is to outline threats with the expectation that applicability statements will have to cover (i.e. mitigate or solve) these threats in some way.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?


The previous document (draft-ietf-roll-security-framework) on which this document is based has had thorough reviews by Rene Struik, JP Vasseur, Michael Richardson and Adrian Farrel, which ultimately contributed to the re-submission of this document.

This document has had review from Stephen Kent and Sean Turner.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?


The Document Shepherd is Robert Cragie. The Responsible Area Director is Adrial Farrel.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.


The Document Shepherd has reviewed the document and has some concerns which will be dealt with prior to publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?


The document has not had a particularly broad review given the subject material.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.


As the document is regarding security threats to the RPL protocol, it is recommended that it is reviewed by the security Area Director.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.


The Document Shepherd has some concerns regarding the treatment of L2 security, which he has raised with the WG Chair.
Tickets created for the issues #150, #151, #152, #153, #154, #155 and #156


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?


The authors have confirmed that there are no IPR disclosures required for full conformance with BCP 78 and BCP 79.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.


There are no IPR disclosures that reference the document.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?


It represents the concurrence of a few individuals. Most of the WG has been silent on this document.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)


No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  -- The document date (December 15, 2013) is 64 days in the past.  Is this
    intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Missing Reference: 'IS07498-2' is mentioned on line 155, but not
    defined
    'This document uses [IS07498-2] model, which includes Authenticati...'

  == Unused Reference: 'RFC4107' is defined on line 1574, but no explicit
    reference was found in the text
    '[RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographi...'

  == Unused Reference: 'RFC4301' is defined on line 1577, but no explicit
    reference was found in the text
    '[RFC4301]  Kent, S. and K. Seo, "Security Architecture for the Inter...'

  == Unused Reference: 'FIPS197' is defined on line 1600, but no explicit
    reference was found in the text
    '[FIPS197]  , "Federal Information Processing Standards Publication 1...'

  == Unused Reference: 'Huang2003' is defined on line 1604, but no explicit
    reference was found in the text
    '[Huang2003] Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. Zh...'

  == Unused Reference: 'I-D.alexander-roll-mikey-lln-key-mgmt' is defined on
    line 1612, but no explicit reference was found in the
    text
    '[I-D.alexander-roll-mikey-lln-key-mgmt] Alexander, R. and T. Tsao, "...'

  == Unused Reference: 'IEEE1149.1' is defined on line 1629, but no explicit
    reference was found in the text
    '[IEEE1149.1] , "IEEE Standard Test Access Port and Boundary Scan Arc...'

  == Unused Reference: 'Kasumi3gpp' is defined on line 1645, but no explicit
    reference was found in the text
    '[Kasumi3gpp] , "3GPP TS 35.202 Specification of the 3GPP confidentia...'

  == Unused Reference: 'Messerges2003' is defined on line 1650, but no
    explicit reference was found in the text
    '[Messerges2003] Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., S...'

  == Unused Reference: 'RFC2080' is defined on line 1671, but no explicit
    reference was found in the text
    '[RFC2080]  Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, Ja...'

  == Unused Reference: 'RFC2453' is defined on line 1676, but no explicit
    reference was found in the text
    '[RFC2453]  Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1...'

  == Unused Reference: 'RFC3830' is defined on line 1682, but no explicit
    reference was found in the text
    '[RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K....'

  == Unused Reference: 'RFC4046' is defined on line 1686, but no explicit
    reference was found in the text
    '[RFC4046]  Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "...'

  == Unused Reference: 'RFC5055' is defined on line 1699, but no explicit
    reference was found in the text
    '[RFC5055]  Freeman, T., Housley, R., Malpani, A., Cooper, D., and W....'

  == Unused Reference: 'RFC5197' is defined on line 1703, but no explicit
    reference was found in the text
    '[RFC5197]  Fries, S. and D. Ignjatic, "On the Applicability of Vario...'

  == Unused Reference: 'RFC5996' is defined on line 1727, but no explicit
    reference was found in the text
    '[RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Intern...'

  == Unused Reference: 'RFC6574' is defined on line 1734, but no explicit
    reference was found in the text
    '[RFC6574]  Tschofenig, H. and J. Arkko, "Report from the Smart Objec...'

  == Unused Reference: 'Szcze2008' is defined on line 1751, but no explicit
    reference was found in the text
    '[Szcze2008] Szczechowiak1, P., Oliveira, L., Scott, M., Collier, M.,...'

  == Unused Reference: 'Wander2005' is defined on line 1764, but no explicit
    reference was found in the text
    '[Wander2005] Wander, A., Gura, N., Eberle, H., Gupta, V., and S. Sha...'

  == Outdated reference: draft-ietf-roll-terminology has been published as
    RFC 7102


    Summary: 0 errors (**), 0 flaws (~~), 21 warnings (==), 1 comment (--).


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.


No formal review required.


(13) Have all references within this document been identified as either normative or informative?


Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?


The normative reference to ZigBee IP needs fixing.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.


Not applicable to an Informational RFC.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.


The publication of this document will not affect the status of any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).


There are no IANA considerations.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.


There are no new IANA registries.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.


There are no parts of the document written in a formal language.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?


i) Type of RFC Requested: Informational
ii) It is the proper type of RFC because the document describes a security threat analysis and not a protocol
iii) The type of RFC is indicated in the title page header


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.


The document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL).  The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks.  A systematic approach is used in defining and evaluating the security threats.  Applicable countermeasures are application specific and are addressed in relevant applicability statements.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?


This document is based upon draft-ietf-roll-security-framework. It was agreed to produce a new document in line with the ROLL WG work item:

Sep 2012: Submit first draft of RPL threat analysis to the IESG to be considered as an Informational RFC

The goal of this document is to outline threats with the expectation that applicability statements will have to cover (i.e. mitigate or solve) these threats in some way.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?


The previous document (draft-ietf-roll-security-framework) on which this document is based has had thorough reviews by Rene Struik, JP Vasseur, Michael Richardson and Adrian Farrel, which ultimately contributed to the re-submission of this document.

This document has had review from Stephen Kent and Sean Turner.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?


The Document Shepherd is Robert Cragie. The Responsible Area Director is Adrial Farrel.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.


The Document Shepherd has reviewed the document and has some concerns which will be dealt with prior to publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?


The document has not had a particularly broad review given the subject material.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.


As the document is regarding security threats to the RPL protocol, it is recommended that it is reviewed by the security Area Director.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.


The Document Shepherd has some concerns regarding the treatment of L2 security, which he has raised with the WG Chair.
Tickets created for the issues #150, #151, #152, #153, #154, #155 and #156


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?


The authors have confirmed that there are no IPR disclosures required for full conformance with BCP 78 and BCP 79.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.


There are no IPR disclosures that reference the document.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?


It represents the concurrence of a few individuals. Most of the WG has been silent on this document.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)


No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  -- The document date (December 15, 2013) is 64 days in the past.  Is this
    intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Missing Reference: 'IS07498-2' is mentioned on line 155, but not
    defined
    'This document uses [IS07498-2] model, which includes Authenticati...'

  == Unused Reference: 'RFC4107' is defined on line 1574, but no explicit
    reference was found in the text
    '[RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographi...'

  == Unused Reference: 'RFC4301' is defined on line 1577, but no explicit
    reference was found in the text
    '[RFC4301]  Kent, S. and K. Seo, "Security Architecture for the Inter...'

  == Unused Reference: 'FIPS197' is defined on line 1600, but no explicit
    reference was found in the text
    '[FIPS197]  , "Federal Information Processing Standards Publication 1...'

  == Unused Reference: 'Huang2003' is defined on line 1604, but no explicit
    reference was found in the text
    '[Huang2003] Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. Zh...'

  == Unused Reference: 'I-D.alexander-roll-mikey-lln-key-mgmt' is defined on
    line 1612, but no explicit reference was found in the
    text
    '[I-D.alexander-roll-mikey-lln-key-mgmt] Alexander, R. and T. Tsao, "...'

  == Unused Reference: 'IEEE1149.1' is defined on line 1629, but no explicit
    reference was found in the text
    '[IEEE1149.1] , "IEEE Standard Test Access Port and Boundary Scan Arc...'

  == Unused Reference: 'Kasumi3gpp' is defined on line 1645, but no explicit
    reference was found in the text
    '[Kasumi3gpp] , "3GPP TS 35.202 Specification of the 3GPP confidentia...'

  == Unused Reference: 'Messerges2003' is defined on line 1650, but no
    explicit reference was found in the text
    '[Messerges2003] Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., S...'

  == Unused Reference: 'RFC2080' is defined on line 1671, but no explicit
    reference was found in the text
    '[RFC2080]  Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, Ja...'

  == Unused Reference: 'RFC2453' is defined on line 1676, but no explicit
    reference was found in the text
    '[RFC2453]  Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1...'

  == Unused Reference: 'RFC3830' is defined on line 1682, but no explicit
    reference was found in the text
    '[RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K....'

  == Unused Reference: 'RFC4046' is defined on line 1686, but no explicit
    reference was found in the text
    '[RFC4046]  Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "...'

  == Unused Reference: 'RFC5055' is defined on line 1699, but no explicit
    reference was found in the text
    '[RFC5055]  Freeman, T., Housley, R., Malpani, A., Cooper, D., and W....'

  == Unused Reference: 'RFC5197' is defined on line 1703, but no explicit
    reference was found in the text
    '[RFC5197]  Fries, S. and D. Ignjatic, "On the Applicability of Vario...'

  == Unused Reference: 'RFC5996' is defined on line 1727, but no explicit
    reference was found in the text
    '[RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Intern...'

  == Unused Reference: 'RFC6574' is defined on line 1734, but no explicit
    reference was found in the text
    '[RFC6574]  Tschofenig, H. and J. Arkko, "Report from the Smart Objec...'

  == Unused Reference: 'Szcze2008' is defined on line 1751, but no explicit
    reference was found in the text
    '[Szcze2008] Szczechowiak1, P., Oliveira, L., Scott, M., Collier, M.,...'

  == Unused Reference: 'Wander2005' is defined on line 1764, but no explicit
    reference was found in the text
    '[Wander2005] Wander, A., Gura, N., Eberle, H., Gupta, V., and S. Sha...'

  == Outdated reference: draft-ietf-roll-terminology has been published as
    RFC 7102


    Summary: 0 errors (**), 0 flaws (~~), 21 warnings (==), 1 comment (--).


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.


No formal review required.


(13) Have all references within this document been identified as either normative or informative?


Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?


The normative reference to ZigBee IP needs fixing.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.


Not applicable to an Informational RFC.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.


The publication of this document will not affect the status of any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).


There are no IANA considerations.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.


There are no new IANA registries.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.


There are no parts of the document written in a formal language.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?


i) Type of RFC Requested: Informational
ii) It is the proper type of RFC because the document describes a security threat analysis and not a protocol
iii) The type of RFC is indicated in the title page header


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.


The document presents a security threat analysis for the Routing Protocol for Low-power and lossy networks (RPL, ROLL).  The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low-power and lossy networks.  A systematic approach is used in defining and evaluating the security threats.  Applicable countermeasures are application specific and are addressed in relevant applicability statements.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?


This document is based upon draft-ietf-roll-security-framework. It was agreed to produce a new document in line with the ROLL WG work item:

Sep 2012: Submit first draft of RPL threat analysis to the IESG to be considered as an Informational RFC

The goal of this document is to outline threats with the expectation that applicability statements will have to cover (i.e. mitigate or solve) these threats in some way.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?


The previous document (draft-ietf-roll-security-framework) on which this document is based has had thorough reviews by Rene Struik, JP Vasseur, Michael Richardson and Adrian Farrel, which ultimately contributed to the re-submission of this document.

This document has had review from Stephen Kent and Sean Turner.


Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?


The Document Shepherd is Robert Cragie. The Responsible Area Director is Adrial Farrel.


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.


The Document Shepherd has reviewed the document and has some concerns which will be dealt with prior to publication.


(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?


The document has not had a particularly broad review given the subject material.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.


As the document is regarding security threats to the RPL protocol, it is recommended that it is reviewed by the security Area Director.


(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.


The Document Shepherd has some concerns regarding the treatment of L2 security, which he has raised with the WG Chair.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?


The authors have confirmed that there are no IPR disclosures required for full conformance with BCP 78 and BCP 79.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.


There are no IPR disclosures that reference the document.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?


It represents the concurrence of a few individuals. Most of the WG has been silent on this document.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)


No.


(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The copyright year in the IETF Trust and authors Copyright Line does not
    match the current year

  -- The document date (December 15, 2013) is 64 days in the past.  Is this
    intentional?


  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Missing Reference: 'IS07498-2' is mentioned on line 155, but not
    defined
    'This document uses [IS07498-2] model, which includes Authenticati...'

  == Unused Reference: 'RFC4107' is defined on line 1574, but no explicit
    reference was found in the text
    '[RFC4107]  Bellovin, S. and R. Housley, "Guidelines for Cryptographi...'

  == Unused Reference: 'RFC4301' is defined on line 1577, but no explicit
    reference was found in the text
    '[RFC4301]  Kent, S. and K. Seo, "Security Architecture for the Inter...'

  == Unused Reference: 'FIPS197' is defined on line 1600, but no explicit
    reference was found in the text
    '[FIPS197]  , "Federal Information Processing Standards Publication 1...'

  == Unused Reference: 'Huang2003' is defined on line 1604, but no explicit
    reference was found in the text
    '[Huang2003] Huang, Q., Cukier, J., Kobayashi, H., Liu, B., and J. Zh...'

  == Unused Reference: 'I-D.alexander-roll-mikey-lln-key-mgmt' is defined on
    line 1612, but no explicit reference was found in the
    text
    '[I-D.alexander-roll-mikey-lln-key-mgmt] Alexander, R. and T. Tsao, "...'

  == Unused Reference: 'IEEE1149.1' is defined on line 1629, but no explicit
    reference was found in the text
    '[IEEE1149.1] , "IEEE Standard Test Access Port and Boundary Scan Arc...'

  == Unused Reference: 'Kasumi3gpp' is defined on line 1645, but no explicit
    reference was found in the text
    '[Kasumi3gpp] , "3GPP TS 35.202 Specification of the 3GPP confidentia...'

  == Unused Reference: 'Messerges2003' is defined on line 1650, but no
    explicit reference was found in the text
    '[Messerges2003] Messerges, T., Cukier, J., Kevenaar, T., Puhl, L., S...'

  == Unused Reference: 'RFC2080' is defined on line 1671, but no explicit
    reference was found in the text
    '[RFC2080]  Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, Ja...'

  == Unused Reference: 'RFC2453' is defined on line 1676, but no explicit
    reference was found in the text
    '[RFC2453]  Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1...'

  == Unused Reference: 'RFC3830' is defined on line 1682, but no explicit
    reference was found in the text
    '[RFC3830]  Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K....'

  == Unused Reference: 'RFC4046' is defined on line 1686, but no explicit
    reference was found in the text
    '[RFC4046]  Baugher, M., Canetti, R., Dondeti, L., and F. Lindholm, "...'

  == Unused Reference: 'RFC5055' is defined on line 1699, but no explicit
    reference was found in the text
    '[RFC5055]  Freeman, T., Housley, R., Malpani, A., Cooper, D., and W....'

  == Unused Reference: 'RFC5197' is defined on line 1703, but no explicit
    reference was found in the text
    '[RFC5197]  Fries, S. and D. Ignjatic, "On the Applicability of Vario...'

  == Unused Reference: 'RFC5996' is defined on line 1727, but no explicit
    reference was found in the text
    '[RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Intern...'

  == Unused Reference: 'RFC6574' is defined on line 1734, but no explicit
    reference was found in the text
    '[RFC6574]  Tschofenig, H. and J. Arkko, "Report from the Smart Objec...'

  == Unused Reference: 'Szcze2008' is defined on line 1751, but no explicit
    reference was found in the text
    '[Szcze2008] Szczechowiak1, P., Oliveira, L., Scott, M., Collier, M.,...'

  == Unused Reference: 'Wander2005' is defined on line 1764, but no explicit
    reference was found in the text
    '[Wander2005] Wander, A., Gura, N., Eberle, H., Gupta, V., and S. Sha...'

  == Outdated reference: draft-ietf-roll-terminology has been published as
    RFC 7102


    Summary: 0 errors (**), 0 flaws (~~), 21 warnings (==), 1 comment (--).


(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.


No formal review required.


(13) Have all references within this document been identified as either normative or informative?


Yes.


(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?


The normative reference to ZigBee IP needs fixing.


(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.


Not applicable to an Informational RFC.


(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.


The publication of this document will not affect the status of any existing RFCs.


(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).


There are no IANA considerations.


(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.


There are no new IANA registries.


(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.


There are no parts of the document written in a formal language.

After discussion with the WG chairs, this I-D has been returned to the WG for more work and a further last call. A new Publication Request will be issues when the document is ready.

[Ballot discuss]
I think this will be a hugely useful RFC but does have a
few things that could be improved.  My discuss points are
small, and perhaps easily fixed, but also I think
important since they relate to why we're still here after
a couple of years.

(1) 6.4 says that consistency with BCP107 is a SHOULD.
That's a MUST, (regardless of how you define MUST:-) Note
that BCP107 does say when you do not need automated key
managment, and when you do. So if you really don't need
AKM then you are still consistent with the BCP. It is not
however ok to be inconsistent with BCP107.

(2) 6.5.1 says: "This protocol-specific security
mechanism SHOULD be made optional within the protocol
allowing it to be invoked according to the given routing
protocol and application domain and as selected by the
system user. " If you mean optional-to-use, that's ok,
but please say so. If you mean optional-to-implement,
that's not clearly ok and I have more questions. Do you
mean optional-to-use? If not, then BCP61 comes into play
for me unless the quoted text only relates to some
mechanisms that counter Byzantine attacks, in which case
you need to be clear that you're not saying that all
integrity mechanisms are optional-to-implement.

[Ballot comment]
I support Sean and Stweart's discuss points.

Note that all my comments below are non-blocking. I'd
be happy to chat about 'em and happier if we ended up
agreeing but that's not needed for this document to
progress as far as I'm concerned.

Some general points first:

- section 6: This says a lot of good things about what
MUST/SHOULD/MAY be used to get better security. But it
seems to say nothing about what MUST be implemented. I
think you really need to make that distinction since the
IETF is mainly concerned with the latter. If you don't
make that distinction, then I fear we'll have to have
that discussion on a case-by-case basis for each of
the applicability statements and some of the value
of this document will be lost. (But the case-by-case
discussion is a viable way to do it too.)

- I was a bit disappointed that this didn't go into more
detail about RPL. The term "DAG" for example doesn't
occur at all. However, its still useful enough as-is I
hope. 

- Cryptographic protocols and implementations can
suffer from side-channel attacks, many of those require
the attacker to send 10's or 100's of thousands of
messages in order to recover a piece of plaintext. That
probably needs to be noted somewhere, and maybe have a
recommendation that LLN nodes ought to react if they see
many many errors in any cryptographic operation.  That
does however need to be balanced against the potential
for DoS that might be created should a bad actor send
many packets spoofing the source address of a victim node
- we don't want the attacker in that case to be able to
take the victim node off the network. Its just a hard
problem, but one that this document probably ought
bring to the attention of RPL implementers who care
about security.

and some specifics....

- 3.2: Non-repudiation is so the wrong term, but don't
feel bad - that's true for almost all uses of the term;-)
I think you ought get rid of that term entirely and maybe
talk about evidence preservation or something (before you
say its not much use in an LLN because of storage
constraints:-)

- 3.2: Same topic. I don't think its correct to say that
you can't do logging. It is fair to say that you can't do
comprehensive or complete logging, but I'd bet almost all
devices that can do RPL could keep a medium sized
circular log at least and many could (e.g. via SD card)
actually keep quite extensive logs, which in my
experience compress excellently. I do agree that log
retrieval via the LLN is not so likely so if a device
will never be visited or hasn't any other interface but
the LLN, then it might not be worth logging, but you
don't say that. Even if you need to get the log via a
serial connection or JTAG its still very valuable in my
experience if you need to investigate some
(mis)behaviour. So overall, I'd suggest you don't write
off logging as much as you currently do.

- 3.4: I'm not sure what "misappropriated" is meant to
mean. Please clarify. I interpreted it as "leaked out"
btw.

- 3.4: I don't think "legitimacy" is a useful term here
and authenticity applies to messages more than
participants

- 3.4: "faithfully" means what?

- 3.4: I was surprised you didn't say that battery
depletion attacks are a potential issue for LBRs in the
last set of bullets here.

- 4.1.1: sniffing is an odd phrase here, maybe better to
say eavesdropping

- 4.2.1: you say attacks can affect convergence of the
routing protocol - that might be worth elaborating on as
its not clear to this (security geek) reader whether
slow/no-convergence is really an attack or (just) an
example of ineffecient routing. If you consider the more
important audience for this draft to be routing folk, then
maybe its ok and they know already. But to put it another
way, I'm not sure that causing convergence to be slower
by a number of seconds is so much of a threat except
in a tiny proportion of LLNs.

- 4.3.1: There's a gap between the text and the bullet
list, its not clear that or how "HELLO flood attacks and
ACK spoofing" with RPL can lead to the threat described.
I don't doubt you're right, but the text doesn't explain
it in a way I can get.

- 4.3.3: Couldn't the routing protocol offer resilience
features that act to help mitigate DoS attacks at other
(lower or higher) layers? I don't see why not in principle
but you appear to dismiss this.

- 5.2.2: I don't get how comparison with historical data
helps in practice, but I guess it could. Might be useful
if there are some papers that could be referenced to help
the reader figure out if they could use this kind of
approach.

- 5.3.1: I don't think "coerce" is right, maybe
"convince" is better.

- 5.3.1: Do ACKs really reduce the probability of attack
success or rather reduce the impact? Seems more like the
latter to me.

- 5.3.4: Wouldn't limiting the capability of nodes to
accept assertions about link or path quality be a
counter to sinkhole attacks? That might be something to
consider at protocol design time, but might also be
something to consider when deploying, e.g. to disallow
any peer from claiming to be an awful lot better than
all other peers?

- 5.3.5: It would have been great to see if there is any
evidence as to the reality of wormhole attacks. I do
sometimes wonder if these are more theoretical than
practical (in terms of offering a real advantage to an
adversary).

- 6.1: s/improve vulnerability/reduce vulnerability/

- 6.1: It might be worth saying that one needs to be
careful in deriving new confidentiality keys from
new integrity keys.

- 6.2: Just to make life more difficult, sorry;-) Logging
of integrity check failures, if done at the wrong place
could actually make a timing side-channel attack more
feasible.

- 6.4: I don't agree that key managment is not directly
a ROLL security requirement. If you need some crypto
then its a requirement, full stop. The question that
arises is whether (and if so how) to meet that requirement
for RPL, or since we are where we are, for specific
RPL applicabililty statements.

- 6.5: When you say that conforming to the system's
target level of security is a MUST, I think you're mixing
up what's mandatory to implement vs. mandatory to use.
Some security mechanisms might well (and are often) MTI
even though there are deployments where they do not need
to be used (at present). And yes, that does lead to
sometimes unused code paths, which is a pain. But being
able to turn that on without e.g. updating firmware might
still be the right answer. (And requiring a secured
firmware update is probably more onerous anyway, though
should also be done.)

[Ballot discuss]

I think this will be a hugely useful RFC but does have a
few things that could be improved.  My discuss points are
small, and perhaps easily fixed, but also I think
important since they relate to why we're still here after
a couple of years.

(1) 6.4 says that consistency with BCP107 is a SHOULD.
That's a MUST, (regardless of how you define MUST:-) Note
that BCP107 does say when you do not need automated key
managment, and when you do. So if you really don't need
AKM then you are still consistent with the BCP. It is not
however ok to be inconsistent with BCP107.

(2) 6.5.1 says: "This protocol-specific security
mechanism SHOULD be made optional within the protocol
allowing it to be invoked according to the given routing
protocol and application domain and as selected by the
system user. " If you mean optional-to-use, that's ok,
but please say so. If you mean optional-to-implement,
that's not clearly ok and I have more questions. Do you
mean optional-to-use? If not, then BCP107 comes into play
again for me unless the quoted text only relates to some
mechanisms that counter Byzantine attacks, in which case
you need to be clear that you're not saying that all
integrity mechanisms are optional-to-implement.

[Ballot comment]

I support Sean and Stweart's discuss points.

Note that all my comments below are non-blocking. I'd
be happy to chat about 'em and happier if we ended up
agreeing but that's not needed for this document to
progress as far as I'm concerned.

Some general points first:

- section 6: This says a lot of good things about what
MUST/SHOULD/MAY be used to get better security. But it
seems to say nothing about what MUST be implemented. I
think you really need to make that distinction since the
IETF is mainly concerned with the latter. If you don't
make that distinction, then I fear we'll have to have
that discussion on a case-by-case basis for each of
the applicability statements and some of the value
of this document will be lost. (But the case-by-case
discussion is a viable way to do it too.)

- I was a bit disappointed that this didn't go into more
detail about RPL. The term "DAG" for example doesn't
occur at all. However, its still useful enough as-is I
hope. 

- Cryptographic protocols and implementations can
suffer from side-channel attacks, many of those require
the attacker to send 10's or 100's of thousands of
messages in order to recover a piece of plaintext. That
probably needs to be noted somewhere, and maybe have a
recommendation that LLN nodes ought to react if they see
many many errors in any cryptographic operation.  That
does however need to be balanced against the potential
for DoS that might be created should a bad actor send
many packets spoofing the source address of a victim node
- we don't want the attacker in that case to be able to
take the victim node off the network. Its just a hard
problem, but one that this document probably ought
bring to the attention of RPL implementers who care
about security.

and some specifics....

- 3.2: Non-repudiation is so the wrong term, but don't
feel bad - that's true for almost all uses of the term;-)
I think you ought get rid of that term entirely and maybe
talk about evidence preservation or something (before you
say its not much use in an LLN because of storage
constraints:-)

- 3.2: Same topic. I don't think its correct to say that
you can't do logging. It is fair to say that you can't do
comprehensive or complete logging, but I'd bet almost all
devices that can do RPL could keep a medium sized
circular log at least and many could (e.g. via SD card)
actually keep quite extensive logs, which in my
experience compress excellently. I do agree that log
retrieval via the LLN is not so likely so if a device
will never be visited or hasn't any other interface but
the LLN, then it might not be worth logging, but you
don't say that. Even if you need to get the log via a
serial connection or JTAG its still very valuable in my
experience if you need to investigate some
(mis)behaviour. So overall, I'd suggest you don't write
off logging as much as you currently do.

- 3.4: I'm not sure what "misappropriated" is meant to
mean. Please clarify. I interpreted it as "leaked out"
btw.

- 3.4: I don't think "legitimacy" is a useful term here
and authenticity applies to messages more than
participants

- 3.4: "faithfully" means what?

- 3.4: I was surprised you didn't say that battery
depletion attacks are a potential issue for LBRs in the
last set of bullets here.

- 4.1.1: sniffing is an odd phrase here, maybe better to
say eavesdropping

- 4.2.1: you say attacks can affect convergence of the
routing protocol - that might be worth elaborating on as
its not clear to this (security geek) reader whether
slow/no-convergence is really an attack or (just) an
example of ineffecient routing. If you consider the more
important audience for this draft to be routing folk, then
maybe its ok and they know already. But to put it another
way, I'm not sure that causing convergence to be slower
by a number of seconds is so much of a threat except
in a tiny proportion of LLNs.

- 4.3.1: There's a gap between the text and the bullet
list, its not clear that or how "HELLO flood attacks and
ACK spoofing" with RPL can lead to the threat described.
I don't doubt you're right, but the text doesn't explain
it in a way I can get.

- 4.3.3: Couldn't the routing protocol offer resilience
features that act to help mitigate DoS attacks at other
(lower or higher) layers? I don't see why not in principle
but you appear to dismiss this.

- 5.2.2: I don't get how comparison with historical data
helps in practice, but I guess it could. Might be useful
if there are some papers that could be referenced to help
the reader figure out if they could use this kind of
approach.

- 5.3.1: I don't think "coerce" is right, maybe
"convince" is better.

- 5.3.1: Do ACKs really reduce the probability of attack
success or rather reduce the impact? Seems more like the
latter to me.

- 5.3.4: Wouldn't limiting the capability of nodes to
accept assertions about link or path quality be a
counter to sinkhole attacks? That might be something to
consider at protocol design time, but might also be
something to consider when deploying, e.g. to disallow
any peer from claiming to be an awful lot better than
all other peers?

- 5.3.5: It would have been great to see if there is any
evidence as to the reality of wormhole attacks. I do
sometimes wonder if these are more theoretical than
practical (in terms of offering a real advantage to an
adversary).

- 6.1: s/improve vulnerability/reduce vulnerability/

- 6.1: It might be worth saying that one needs to be
careful in deriving new confidentiality keys from
new integrity keys.

- 6.2: Just to make life more difficult, sorry;-) Logging
of integrity check failures, if done at the wrong place
could actually make a timing side-channel attack more
feasible.

- 6.4: I don't agree that key managment is not directly
a ROLL security requirement. If you need some crypto
then its a requirement, full stop. The question that
arises is whether (and if so how) to meet that requirement
for RPL, or since we are where we are, for specific
RPL applicabililty statements.

- 6.5: When you say that conforming to the system's
target level of security is a MUST, I think you're mixing
up what's mandatory to implement vs. mandatory to use.
Some security mechanisms might well (and are often) MTI
even though there are deployments where they do not need
to be used (at present). And yes, that does lead to
sometimes unused code paths, which is a pain. But being
able to turn that on without e.g. updating firmware might
still be the right answer. (And requiring a secured
firmware update is probably more onerous anyway, though
should also be done.)

[Ballot comment]
History is sometimes amusing: I see that all of the capitalized words in section 6 were due to a comment made by Peter Saint Andre during evaluation of draft-ietf-roll-security-framework saying that things should be capitalized. Now you have ADs saying they shouldn't be. Isn't that wonderful? I don't think you need to go back to lowercase, but I think you do need to make one change:

One way or the other, you need to remove the reference to 2119 at the top of the document. What you're doing in section 6 is not 2119 usage, and you've explained in section 6 what you are doing with those capitalized terms, so the reference to 2119 (and the template text at the top of the document) are just wrong. Yes, the idnits checker will complain. There is no requirement that your document pass idnits. You just tell the RFC Editor that this document is not using 2119 and you intended not to include the reference; end of story. I'm not going to bother putting a DISCUSS on the document for this unless Adrian really insists; I trust that you all can just take care of it.

Now, that leaves Barry, Brian, and Joel's question about whether to capitalize it all. Like Barry, I'm not convinced it matters. You explained how you're using the terms, and I think that's fine. It may reduce confusion if you lowercase or choose other "magic" words, but I think that choice is entirely up to the WG.

[Ballot discuss]
I have a whole bunch of problems with this draft, but understand that this is part of way to get out of the current not so great situation.  Many of my comments lined up with the secdir review, but since Stewart called it out in his discuss I'll support him.  Here's some of my own:

0) This draft boils down to this paragraph if I'm not mistaken:

  A ROLL protocol MUST be made flexible by a design that offers the
  configuration facility so that the user (network administrator) can
  choose the security settings that match the application's needs.
  Furthermore, in the case of LLNs, that flexibility SHOULD extend to
  allowing the routing protocol security requirements to be met by
  measures applied at different protocol layers, provided the
  identified requirements are collectively met.

I'm absolutely fine with the first sentence.  I'm even okay with the second sentence it gets done at the application layer all the time, but at the application layer they can all point to something that's all specified up and has MTI etc (think TLS).  If we end up doing that here then something similar needs to end up happening.  If use cases are so broad that they can't possibly pick an underlying security mechanism then you need to try again but with a  smaller net.

1) s3.2: Adding "misuse" in the integrity strikes me as wrong.  It's about determining whether data has changed.  The examples used are about delayed or replayed messages which seem to be better characterized as availability.

2) s3.2: How on is non-repudiation going to apply to these tiny little assets?  I see how I, a person, can repudiate that I sent a message and I can see how you, as a person, can repudiate something else.  Are two nodes going to be claiming one sent something while the other will say no I didn't?  I hear all the time we can't do this and we can't do that because these are so constrained but you're going to log and capture on-going messages - color me confused?  I think you should say non-repudiation applies to people not to device-to-device/automated communications.

4) s3.4: Not this one is likely to be cleared after an email exchange or two because there's not much for the authors to do…

This made my head pop because I thought the only security defined in the RFC 6550 has confidentiality baked in.  So are we dumping the security solution in rpl?

With regard to confidentiality, protecting
the routing/topology information from eavesdropping or unauthorized
exposure may be desirable in certain cases but is in itself less
pertinent in general to the routing function.

[Ballot comment]
1) s1/s3/3.1/3.2: The CIA model is one that's great, but in s3 your list security services list starts off with "proper authorization for actions" and then talk about authentication next.  Clearly authorization and authentication need to be added in to s3.2 -no?  Any chance of just changing to the 5 (confidentiality, integrity, authentication, access control, and non-repudiation) listed in ISO 7498-2?  You ever get a stable international reference.  You don't need to have that awkward lead-in about non-repudiation in s3.2. and you'd only need to add one availability?  If you're going to stick with CIA then please add authorization and authentication in s3.2.

2) s3: After reading the first paragraph in s3 and comparing it to the output of the IAB workshop (RFC1636) I'm left wondering if it's doing the same thing.  RFC 1636 says:

  Securing the routing protocols seems to be a straightforward
  engineering task.  The workshop concluded the following.

  a)  All routing information exchanges should be
        authenticated between neighboring routers.

  b)  The sources of all route information should be
        authenticated.

  c)  Although authenticating the authority of an injector of
        route information is feasible, authentication of
        operations on that routing information (e.g.,
        aggregation) requires further consideration.

S3 closes with:

  In the case of routing security the focus is directed
  towards the elements associated with the establishment and
  maintenance of network connectivity.

The word focus kind of threw me and later in s3.4 you list the fundamental functions of a routing protocol.  Is the threats or the things you're trying to secure.  And, as Steve pointed out in the secdir review most think of routing security is ensuring the proper functioning of the routing protocol.  And, you say you're using definitions from RFC 4949 but the one for "security".

Later in the paragraph you have "authentication, and potentially integrity, and confidentiality" kind of hangs there after authorization.  Authentication, integrity, and confidentiality of what?  Also if you're going to do authentication I guess you might not need integrity, but I'd sure like to know how that happens.

Maybe some tweaks could solve all this:

Routing security, in essence, is about ensuring the routing protocol operates correctly [insert reference if there is one].  It entails measures to ensure ...

and then (injectors was the IAB's word and maybe we can come up with a better one - or we define a new term in the definitions section)

State changes would thereby involve not only authorization of injector's actions, authentication of injectors, authentication, integrity, and potentially confidentiality of routing data, but also proper order of state changes through timeliness, since seriously delayed state changes, such as commands or updates of routing tables, may negatively impact system operation.

3) s3/3.1: in s3 you say:

A security assessment can
therefore begin with a focus on the assets or elements of information
that may be the target of the state changes and the access points in...

and in s3.1 you say:

An asset implies an important system component (including
information, process, or physical resource),

But asset is also defined in RFC 4949 as:

  $ asset
    (I) A system resource that is (a) required to be protected by an
    information system's security policy, (b) intended to be protected
    by a countermeasure, or (c) required for a system's mission.

resource is better than component in my mind (see definition in RFC 4949) so how about the following in s3:

A security assessment can
therefore begin with a focus on the assets [RFC4949]
that may be the target of the state changes and the access points in…

and in s3.1:

An asset is an important system resource (including
information, process, or physical resource),

4) Please provide a pointer to the concept of "control plane".  Would RFC 6192 do as a pointer or maybe add definitions in the definitions section:

control plane: Supports routing and management functions.

forward plane: Responsible for receiving a packet on an incoming interface, performing a lookup to identify the packet's next hop and determine the best outgoing interface towards the destination, and forwarding the packet out through the appropriate outgoing interface.

Also, are we just talking about control plane security here?  If that's true can we say way, way sooner - like in the abstract/introduction?

abstract:
  A systematic approach is used in defining and evaluating the security
  threats for the control plane.

and then else where as appropriate

5) s3.1: r/components and mechanisms/assets, points of access, and process

6) s3.1: It's worth reiterating that the Figure is just about the control plane:

  All of this is done on the control plane. (assuming it is)

7) s3.1: The "route generation" process is missing from the Asset/PoA lists shouldn't it be there?.  Also there's a database but it's not listed is that part of "memory"?  Isn't "node" without a qualifier missing too?

8) s3.2: I thought this was about the control plane?  Why does the availability paragraph talk about forwarding "services"?

9) s3.2: The last paragraph has to be more tightly coupled to ROLL.  I'm afraid of a food fight between the various routing security groups that are doing work in this space because they're not all implementing enforcement mechanisms for the services described in s3.2.

10) s3.3: Please add sleepy node to the definitions section: maybe:

  sleepy node: A node that is not functional, but immediately available.

11) s3.3: What does this mean and why:

  In addition, the choices of security mechanisms are more stringent.

12) s3.3: Highly directional traffic: Are you trying to say that the LBRs are higher valued targets and warrant something different than the regular nodes?

13) s3.4: misappropriated seems like the wrong word based on later sections.  Masquerade seems like what you're trying to protect against, but that's covered by the peer authentication process.

14) s3.4: How about:

In conjunction, it is necessary to be assured of

o  the authenticity and legitimacy of the participants of the routing
    neighbor discovery process;

NEW:

In conjunction, it is necessary to be assured that

  o  authorized peers authenticate themselves during the routing
      neighbor discovery process;

15) s3.4: I think you could drop eavesdropping and just say unauthorized exposure

16) s4: We need to either define the threat sources or point to RFC 4953.  There's really only two outsiders and byzantine.

17) s4.1.1: r/sniffing (passive/passive wiretapping (reading
            r/(evaluation/(e.g., evaluation

18) 4.2.2: identity misappropriation is really about peer authentication and masquerading

19) s4.3.2: nice ascii art

20) s5.1.1: encryption does not counter deliberate exposure attacks.

21) s5.1.2: Passive wiretapping (“sniffing” to the authors) does not include device compromise.

22) s5.1.3: TA is always a passive attack, so the description here “… may be passive…” is wrong.  Just strike may be passive.

23) s5.2.3: r/liveliness/liveness

24) s5.3.2: r/ energy store quicker/ energy store more quickly

25) s6: difficult to parse: The assessments and analysis in Section 4 examined all areas of threats and attacks that could impact routing, and the countermeasures presented in Section 5 were reached without confining the consideration to means only available to routing.

26) s6.1: r/and improve vulnerability against other more direct attacks/and reduce vulnerabilities relative to other attacks

27) s6.2: Can't do security but can keep logs ;)

28) s6.4: r/Security Key Management/Key Management

29) s6.5.1: r/diversified needs/diverse needs

30) I have to admit that I fully expect a consideration about sleep nodes' friend grumpy node.  He's likely to cause all the problems.

[Ballot comment]
Thanks for a well written and important document. I particularly liked the fact that you treated byzantine attacks and key management as a part of the analysis.

A couple of small comments, however:

Section 6.5.1 (Architecture) misses a few aspects on the comparison lower layer vs. routing protocol layer security. Everything that you say about it is correct, but one thing you do not talk about are the problems of providing the exact security services to upper layers that they need. Some of the typical issues include the need to access security information at the routing layer that may be unaware of the exact security parameters, peer identifiers, and other aspects that happened at a lower layer. Similarly, some applications may need security policies that are not easily expressed in crude lower-layer policy models (such as packet filter patterns). A lower-layer mechanism may be run hop-by-hop, whereas the routing layer mechanism may be end-to-end or even secure data objects rather than packets.

The document also touches very little on deployment aspects of the potential security models. In my view, those are often the hardest to solve in a satisfactory manner. I liked the few words that Section 6.4 said about credential configuration, however.

[Ballot comment]
This is one of those "I trust others" ballots: I trust the Sec ADs to be especially thorough on this document, and on a quick run-through I'm happy to let them handle the main issues.

I also have to agree with Brian that using SHOULD and MAY in Section 6 in a way that varies from the meaning in RFC 2119 is, though it's explained, likely to lead to some level of confusion.  That said, given what this document is describing and the fact that strict interpretation according to 2119 doesn't make sense, I think it will work well enough, and, in the end, I'm OK with it.

[Ballot discuss]
From a routing point of view I thought that this was well written, but I am concerned that the security reviewer had considerable comments which appear to be currently unresolved.

Adrian points to:

http://www.ietf.org/mail-archive/web/secdir/current/msg03848.html

However this indirectly refers to a larger body of issues posted here:

http://www.ietf.org/mail-archive/web/secdir/current/msg03712.html

and the security reviewer only re-lists a subset  of these in note 03848 noting that only the typos were addressed in the -01 version of the text.

[Ballot comment]
while the disclaimer on 2119 language in section six is fairly clear I'd rather see it simply not use it. e.g. switch to lower case leave the disclaimer more or less intanct.

[Ballot comment]
The authors are working on the SecDir review by Stephen Kent and expect to address the issues before the document appears on a telechat.
http://www.ietf.org/mail-archive/web/secdir/current/msg03848.html

IANA has reviewed draft-ietf-roll-security-threats-00, which is
currently in Last Call, and has the following comments:

IANA understands that, upon approval of this document, there are no
IANA Actions that need completion.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (A Security Threat Analysis for Routing over Low Power and Lossy Networks) to Informational RFC


The IESG has received a request from the Routing Over Low power and Lossy
networks WG (roll) to consider the following document:
- 'A Security Threat Analysis for Routing over Low Power and Lossy
  Networks'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-01-21. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

  This document presents a security threat analysis for routing over
  low power and lossy networks (LLN).  The development builds upon
  previous work on routing security and adapts the assessments to the
  issues and constraints specific to low power and lossy networks.  A
  systematic approach is used in defining and evaluating the security
  threats.  Applicable countermeasures are application specific and are
  addressed in relevant applicability statements.  These assessments
  provide the basis of the security recommendations for incorporation
  into low power, lossy network routing protocols.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/ballot/


No IPR declarations have been submitted directly on this I-D.

Hi,

Dear AD could you please proceed with the publication of

(1)  What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the proper type
of RFC? Is this type of RFC indicated in the title page header?

The intended track of the RFC is Informational, and the RFC type is indicated in
the title page header.

(2) The IESG approval announcement includes a Document Announcement Write-Up.
Please provide such a Document Announcement Write-Up. Recent examples can be
found in the "Action" announcements for approved documents. The approval
announcement contains the following sections:

Summary:


  In recent times, networked electronic devices have found an
  increasing number of applications in various fields.  Yet, for
  reasons ranging from operational application to economics, these
  wired and wireless devices are often supplied with minimum physical
  resources; the constraints include those on computational resources
  (RAM, clock speed, storage), communication resources (duty cycle,
  packet size, etc.), but also form factors that may rule out user
  access interface (e.g., the housing of a small stick-on switch), or
  simply safety considerations (e.g., with gas meters).  As a
  consequence, the resulting networks are more prone to loss of traffic
  and other vulnerabilities.  The proliferation of these low power and
  lossy networks (LLNs), however, are drawing efforts to examine and
  address their potential networking challenges.  Securing the
  establishment and maintenance of network connectivity among these
  deployed devices becomes one of these key challenges.

  This document presents a framework for securing Routing Over LLNs
  (ROLL) through an analysis that starts from the routing basics.  The
  objective is two-fold.  First, the framework will be used to identify
  pertinent security issues.  Second, it will facilitate both the
  assessment of a protocol's security threats and the identification of
  the necessary features for development of secure protocols for the
  ROLL Working Group.

  The approach adopted in this effort proceeds in four steps, to
  examine security issues in ROLL, to analyze threats and attacks, to
  consider the countermeasures, and then to make recommendations for
  securing ROLL.  The basis is found on identifying the assets and
  points of access of routing and evaluating their security needs based
  on the Confidentiality, Integrity, and Availability (CIA) model in
  the context of LLN.


  Security, in essence, entails implementing measures to ensure
  controlled state changes on devices and network elements, both based
  on external inputs (received via communications) or internal inputs
  (physical security of device itself and parameters maintained by the
  device, including, e.g., clock).  State changes would thereby involve
  proper authorization for actions, authentication, and potentially
  confidentiality, but also proper order of state changes through
  timeliness (since seriously delayed state changes, such as commands
  or updates of routing tables, may negatively impact system
  operation).  A security assessment can therefore begin with a focus
  on the assets or elements of information that may be the target of
  the state changes and the access points in terms of interfaces and
  protocol exchanges through which such changes may occur.  In the case
  of routing security the focus is directed towards the elements
  associated with the establishment and maintenance of network
  connectivity.


Working Group Summary:

No discontent. Once again, few comments, request for clarifications that have
all been addressed by in this revision.

Document Quality:

draft-ietf-roll-security-threats-00 is a revision of draft-ietf-roll-security-framework-07 which
ran into a logjam at the IESG process, and sat for 400 days.  The title has been changed, and
the focus of the document is on security threats, rather than solutions. Section 7 was removed:
this is the result of discussion with the IESG on where and how security issues will be addressed.

The goal of this new document is to outline threats with the expectation that applicability statements
will have to cover (i.e. mitigate or solve) these threats in some way.  Please read this document and
ask if the questions it asks are clear enough.

Personnel:

The Document Shepherd is JP Vasseur (ROLL co-chair) and the responsible Area
Director is Adrian Farrel (AD Routing Area)

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for publication,
please explain why the document is being forwarded to the IESG.

The document is sound, has received a very good level of attention and reviews
including from the Shepherd prior to issuing the publication request, and is
ready for publication as experimental track.

(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?

No Concern.

The I-D has been discussed in great detail by a number of key members of the
Working group. Number of comments have been made on the mailing list during two
WG Last Calls and have all been addressed in this revision. Note that several
tickets have been opened and have been successfully closed.

(5) Do portions of the document need review from a particular or from broader
perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or
internationalization? If so, describe the review that took place.

No need for broader review.

(6) Describe any specific concerns or issues that the Document Shepherd has with
this document that the Responsible Area Director and/or the IESG should be aware
of? For example, perhaps he or she is uncomfortable with certain parts of the
document, or has concerns whether there really is a need for it. In any event,
if the WG has discussed those issues and has indicated that it still wishes to
advance the document, detail those concerns here.

No particular concern. Some questions were raised has to whether using a
pro-active protocol in a "reactive" way was scalable; thus the choice to advance
the document along the experimental track.

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed. If not, explain why?

Yes. I have personally checked with all co-authors of the document.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.

No.

(9) How solid is the WG consensus behind this document? Does it represent the
strong concurrence of a few individuals, with others being silent, or does the
WG as a whole understand and agree with it?

Good consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent?
If so, please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

No threats. No discontent.

(11) Identify any ID nits the Document Shepherd has found in this document. (See
http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

Checks have been made. No Errors.

(12) Describe how the document meets any required formal review criteria, such
as the MIB Doctor, media type, and URI type reviews.

Not applicable.

(13) Have all references within this document been identified as either
normative or informative?

References split has been done.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative references
exist, what is the plan for their completion?

The only normative references are to RFCs.

(15) Are there downward normative references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

No

(16) Will publication of this document change the status of any existing RFCs?
Are those RFCs listed on the title page header, listed in the abstract, and
discussed in the introduction? If the RFCs are not listed in the Abstract and
Introduction, explain why, and point to the part of the document where the
relationship of this document to the other RFCs is discussed. If this
information is not in the document, explain why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA
registries include a detailed specification of the initial contents for the
registry, that allocations procedures for future registrations are defined, and
a reasonable name for the new registry has been suggested (see RFC 5226).

The IANA action is properly documented.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful in
selecting the IANA Experts for these new registries.

The IANA section specifies no new registries.

(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML
code, BNF rules, MIB definitions, etc.

No other automated checks performed.