A Security Framework for Routing over Low Power and Lossy Networks
draft-ietf-roll-security-framework-07

This document is returned to the working group for further work. Under the plan put in place by the WG chairs, this document will be re-cast as a Threat Analysis, and further security work will be done in other documents.

[Ballot comment]
#1 The document uses terminology very slightly differently when
compared to others in e.g. the security area. It might be worth
going throuh rfc4949 and trying to change terminology here to
match that. (Or maybe you did, and 4949 is wrong - 4949 is so
long its hard to know;-)

#2 Non-repudiation is a nonsense (as a network service) and is
better omitted from documents like this entirely. In this case
you might be able to s/non-repudiation/evidence gathering/ with
a few edits to fix this.

#3 I don't understand "routing in LLNs needs to bootstrap the
authentication process" - I guess I'm not sure who's
authentication to whom is being discussed.

#4 "Only when a validated and authenticated node association is
completed will routing exchange be allowed to proceed using
established session confidentiality keys and an agreed
confidentiality algorithm. " You can have confidentiality to
counter sniffing without authentication, but at the expense of
remaining vulnerable to MITM attacks. Might be too big a
change, but sniffing and MITM are different attacks really.

#5 "This session key shall be applied in conjunction" should
that be a 2119 SHALL?

#6 A reference for JTAG might be useful for some readers

#7 s/it associated external memory/its associated external
memory/

#8 I can't parse this: "Since remote access is not invoked as
part of a routing protocol security of routing information
stored on the node against remote access will not be
addressable as part of the routing protocol." Maybe it just
needs rephrasing.

#9 5.2 says that it won't include physical attacks, but the
title of 5.2.1 includes the word "tampering" which is usually
used in the context of physical attacks.  In 5.2.1 tampering
can be replaced with the more common "message modification" or
"message insertion" etc. as appropriate.

#10 5.2.2 says "...while there is not necessarily tampering"
which needs rephrasing.

#11 5.2.5 could also note that replay-caches are usually needed
to counter clock-skew (esp in LLN devices where you may need 24
hour wide windows) and that those can be problematic on the
kind of device considered here.

#12 There's either a missing reference or better explanation of
byzantine attacks. A reference would be better.

#13 5.2.5 talks about "routing principals" being authenticated
- is that a well defined term for roll/RPL? (It could be a
machine, a process, a thing in the context of a dodag...) The
very next paragraph says "routing entities" - are those the
same?

#14 5.2.5 - without a reference or explanation its not
sufficiently obvious that ospf or isis can directly detect
these attacks by comparing different messages - adding a
reference would be best.

#15 5.3.2 - you don't really drain an engrgy budget, but rather
an energy store

#16 5.3.2 - not sure that saying verify certs before signatures
is always right - that might involve CRL retrievals that could
amplify an attack if an attacker just presents a highly complex
cert path with a bogus signature - where's the evidence this
way is better?  If you have it, it should be
included/referenced.

#17 5.3.2 - I don't get the relevance of s/mime at the end of
5.3.2 - what part of (the 45 pages of) rfc5751 is relevant?

#18 5.3.4 - a reference would be good

#19 5.3.5 - a reference would be good

#20 6.1 - privacy isn't right here, it appears to be a
confidentiality service that's being required

#21 6.1 - it'd be better to be clear about what's mandatory to
implement vs. mandatory to use, 6.1's "MUST provide privacy..."
seems to be calling for mandatory-to-use. (A question on that,
are there really no LLN's where all geographic information is
obvious? e.g.  a very small scale network, or a network where
node position is inherently public, say a node on each bus-stop
- maybe a SHOULD is more correct here?)

#22 6.1 - asking that key lengths (strengths really) be "in
accordance" with requirements is a bit optimistic - how is one
supposed to know that 67bit strength is ok or not? We usually
do this in a gross manner, currently 80/128 bits of strength.
Its also typical to say that commensurate strength is at least
a SHOULD requirement. Its also quite unlikely that e.g. FIPS
accredited interfaces for 67bit strength ciphers will be
developed, so I'm very unsure that this is worthwhile. I also
think its less likely that you'd be able to justify 40bit
strength (maybe worth a try, not sure) in which case choices
other than 80bit and 128 equivalent strength seem wrong.

#23 6.1 has MAY requirements for tunnelling and load-balancing
without any explanation or reference - I don't get what that's
for anyway.

#24 6.2's 1st MUST parenthetically implies that integrity has
to be applied after confidentiality. Sign-then-encrypt is more
common, though in LLNs there can be reasons to do
encrypt-then-sign (or both). However, I'm surprised that you're
mandating something like that here - is that deliberate?

#24 6.2's 2nd MUST requires verifying "authenticity and
liveliness" - what are those?o

#25 6.2 - another weird bit of terminology; "MAY use security
auditing mechanisms that are external to routing to verify the
validity..." Auditing is not a run-time decision making
mechanism in all cases of which I'm aware.

#26 6.3 - I don't understand the impact of this section which
contains only MAY requirements. This also needs rephrasing
since there's no antecedent for the MAY statements, and
the last one is hard to understand - what's an "insight"?

#27 title of 6.4 is odd - it reads like an add-on

#28 6.4 - does "MUST secure these mechanisms" mean "MUST use"?
If so, what's special about multi-/any-cast? (vs.  unicast that
is)

#29 6.4 - it makes no sense to me that a node MUST have
physical security countermeasures just because it doesn't only
use unicast. Is that what it really says here? (Sentence
starting "Furthermore, the nodes MUST provide...")

#30 6.4 "will assume" isn't 2119 language esp. when quoting
bcp107 here it seems odd, suggest adding some 2119 statement.

#31 6.4 "public certificates" is wrong, you mean "public key
certificates"

#32 6.4 - rfc3029 is a *very* odd citation - why that
experimental non-repudiation related protocol? I am unaware of
any LLN related experimental deployment of 3029 which is just
not designed for challenged environments, never mind anything
better. (Such as real deployment.)

#33 6.4 "must support means for secure config..." s/must/MUST/
probably?

#34 6.4 - One sentence has a *lot* of MUSTs in it - "secure
configuration, device authentication, and adherence to secure
key wrapping" and that's for cases where PKI it too
heavyweight?  I don't think we'll benefit from more security
fig-leaves for the Internet and this sounds like one. I think
this aspect needs more real thought - for an LLN that cannot
support the complexity of PKI what do we think is reasonably
required? (I'm ok to help try figure that out, but I do not
believe we know the answer right now.)

#35 6.4 - I like the idea of using IKE/IPsec where
useful/possible.  However, (presumably transport mode) IPsec
will only supply security services for moving roll/RPL messages
between nodes, so what about the other services needed? E.g. I
can't see how the 2nd bullet from 6.2 could be satisfied by
IPsec.

#36 6.4 - It seems a tall order for roll to "adapt" things like
mikey in order to make progress. Is that really what you think
is needed? If so, what kind of adaptation and where might that
be done?

#37 6.5.1 - is this what you meant to say: "On the other hand,
providing four individual domain designs that attempt to a
priori match each individual domain is also very likely to
provide a suitable answer given the degree of network
variability even within a given domain; furthermore, the type
of link layers in use within each domain also influences the
overall security." It reads like it ought to say "is also very
unlikely" but it says "likely," which is also not that easy to
believe.

#38 6.5.1: "Instead, the framework implementation approach
recommended for optional, routing protocol-specific measures
that can be applied separate from or together with flexible
transport network mechanisms." Should that be "recommended is
for"? (Couple more typos in that paragraph as well.)

#39 6.5.2: typo: "and allow for flexible expiration scheme of
authentication credentials" s/for flexible/for a flexible/

#40 6.5.2: typo: "There and other.." (and more typos in that
paragraph)

[Ballot discuss]
Since I've taken over Tim's discuss, I've just had a read to
ensure I understand this. I read this document and section 10
of roll-rpl.

I believe that the core of Tim's discuss is that there is no
specification for how the authenticated mode of roll-rpl is to
be done, and specifically using public key based mechanisms
for key distribution.

That seems to still be the case, so if I'm right there, then
the discuss should remain. If not, (Tim?) then I may be
misunderstanding, and should clear. I don't see anything in
this document, the charter milestones or the set of WG docs
that looks like it will address this.

I'd be happy to clear were there to be a good specification
of how to do e.g. a signature based authenticated mode, or
a public key based way to distribute keys for an
authenticated mode, or even a kerberos-like way to
distribute secret keys for an authenticated mode. While this
will all be optional to implement, its absence is really
not consistent with bcp107.

Having read the thing, I also have a bunch of comments (below)
and one additional question about RPL to which I'd love to know
the answer. (It may be that the answer is in roll-rpl already
but I didn't read all 163 pages;-).

My question: with pre-shared keys, what prevents reflection or
re-direction attacks where a MACed message is captured and
either reflected back to the sender or else sent to another
node using the same pre-shared secret? In order to avoid having
to exhaustively analyse the protocol, its normal to try to
prevent such attacks inside the crypto mechanism.

[Tim's original discuss text is below]

I think this is a really good document, and support its publication.

However, I think some of the issues I was persuaded to remove from my discuss on
roll-rpl because they would be
more appropriate in this document were omitted.
I am specifically concerned about punting the details on public key
distribution, then finding they are not covered here either.

Did I get the wrong document?  Where are those issues going to be addressed?

I will hold this discuss while we sort out the best place to address these
issues...

[Ballot discuss]
The Gen-ART Review by David Black raised a significant concern. The
  confidentiality and privacy requirements are SHOULD.  It seems to me
  that they ought to be "MUST implement" so that every implementation
  can be configured to make use of confidentiality and privacy.  An
  alternative would be "MUST implement" coupled with "SHOULD use when"
  statements, or "SHOULD" coupled with "geographic information MUST NOT
  be handled when confidentiality protection is not enabled."

[Ballot discuss]
Taking over Tim's discuss.

I think this is a really good document, and support its publication.

However, I think some of the issues I was persuaded to remove from my discuss on
roll-rpl because they would be
more appropriate in this document were omitted.
I am specifically concerned about punting the details on public key
distribution, then finding they are not covered here either.

Did I get the wrong document?  Where are those issues going to be addressed?

I will hold this discuss while we sort out the best place to address these
issues...

[Ballot discuss]
Taking over Tim's discuss.

I think this is a really good document, and support its publication.

However, I think some of the issues I was persuaded to remove from my discuss on
roll-rpl because they would be
more appropriate in this document were omitted.
I am specifically concerned about punting the details on public key
distribution, then finding they are not covered here either.

Did I get the wrong document?  Where are those issues going to be addressed?

I will hold this discuss while we sort out the best place to address these
issues...

[Ballot comment]
(no action required) Thanks for the clear and concise discussion on non-repudiation.  And, that's some sweet ASCII-art.

#1) Section 5.3.4:

  On the other hand, geographic
  position is a sensitive information that may have security and/or
  privacy consequences.

I guess I'd argue geographic data does have security/privacy consequences as opposed to may have.

[Ballot discuss]
Unfortunately, I didn't have time to get all the way through this document.

#1) Two things in Section 5.1.1:

  To prevent deliberate exposure, the process that communicating nodes
  use for establishing communication session keys must be symmetric at
  each node so that neither node can independently weaken the
  confidentiality of the exchange without the knowledge of its
  communicating peer.

What does symmetric at each node imply?  Is this implying symmetric keying or something else?

Is there a requirement to come back from a deliberate exposure or to exclude a node that's known to be bad from doing it again? I.e., you're behaving badly and you do it a lot so we're going to get the other nodes to not communicate with you.

#2) Section 5.1.3: Another way to counter traffic analysis is for two nodes to always have the same amount of traffic on the link.

#3) Section 5.1.3: I think it's worth noting that as a consequence of sending traffic all over the place is that now a wider community can look at the flows.  It's a privacy concern.

#4) Section 5.1.4: I think it's worth noting that signing the firmware can help with the determining the authenticity of the provided code and that the process is initiated by an authorized entity.

#5) Section 5.3.2: There are other kinds of overloading attacks.  For example, I send you a really, really big key and it takes you forever to process it.  Should there be some warnings like we put in RFC 5751 (tweaked of course):

  Receiving agents that validate signatures and sending agents that
  encrypt messages need to be cautious of cryptographic processing
  usage when validating signatures and encrypting messages using keys
  larger than those mandated in this specification.  An attacker could
  send certificates with keys that would result in excessive
  cryptographic processing, for example, keys larger than those
  mandated in this specification, which could swamp the processing
  element.  Agents that use such keys without first validating the
  certificate to a trust anchor are advised to have some sort of
  cryptographic resource management system to prevent such attacks.

#6) Section 6.1:

Should I read "SHOULD provide payload encryption;" as an implementation MUST support but not always use payload encryption?

Should I read "SHOULD provide privacy when geographic information is used (see, e.g., [RFC3693]);" as an implementation MUST support but not always use payload encryption when geographic information is used?

#7) Section 6.2: Tweak first bullet

o MUST provide and verify message integrity

#8) Doesn't this need to say something about making/storing keys?  If we're going to rely on keys generated by these devices then you might want to consider making the keys someplace else?  That's got lots of concerns.

[Ballot comment]
(no action required) Thanks for the clear and concise discussion on non-repudiation.  And, that's some sweet ASCII-art.

#1) Section 5.3.4:

  On the other hand, geographic
  position is a sensitive information that may have security and/or
  privacy consequences.

I guess I'd argue geographic data does have security/privacy consequences as opposed to may have.

#2)

[Ballot discuss]
Unfortunately, I didn't have time to get all the way through this document.

#1) Two things in Section 5.1.1:

  To prevent deliberate exposure, the process that communicating nodes
  use for establishing communication session keys must be symmetric at
  each node so that neither node can independently weaken the
  confidentiality of the exchange without the knowledge of its
  communicating peer.

What does symmetric at each node imply?  Is this implying symmetric keying or something else?

Is there a requirement to come back from a deliberate exposure or to exclude a node that's known to be bad from doing it again? I.e., you're behaving badly and you do it a lot so we're going to get the other nodes to not communicate with you.

#2) Section 5.1.3: Another way to counter traffic analysis is for two nodes to always have the same amount of traffic on the link.

#3) Section 5.1.3: I think it's worth noting that as a consequence of sending traffic all over the place is that now a wider community can look at the flows.  It's a privacy concern.

#4) Section 5.1.4: I think it's worth noting that signing the firmware can help with the determining the authenticity of the provided code and that the process is initiated by an authorized entity.

#5) Section 5.3.2: There are other kinds of overloading attacks.  For example, I send you a really, really big key and it takes you forever to process it.  Should there be some warnings like we put in RFC 5751 (tweaked of course):

  Receiving agents that validate signatures and sending agents that
  encrypt messages need to be cautious of cryptographic processing
  usage when validating signatures and encrypting messages using keys
  larger than those mandated in this specification.  An attacker could
  send certificates with keys that would result in excessive
  cryptographic processing, for example, keys larger than those
  mandated in this specification, which could swamp the processing
  element.  Agents that use such keys without first validating the
  certificate to a trust anchor are advised to have some sort of
  cryptographic resource management system to prevent such attacks.

#6) Section 6.1:

Should I read "SHOULD provide payload encryption;" as an implementation MUST support but not always use payload encryption?

Should I read "SHOULD provide privacy when geographic information is used (see, e.g., [RFC3693]);" as an implementation MUST support but not always use payload encryption when geographic information is used?

#6) Section 6.2: Tweak first bullet

o MUST provide and verify message integrity

[Ballot discuss]
I think this is a really good document, and support its publication.

However, I think some of the issues I was persuaded to remove from my discuss on roll-rpl because they would be
more appropriate in this document were omitted.  I am specifically concerned about punting the details on public key
distribution, then finding they are not covered here either.

Did I get the wrong document?  Where are those issues going to be addressed?

I will hold this discuss while we sort out the best place to address these issues...

[Ballot discuss]
The Gen-ART Review by David Black raised a significant concern. The
  confidentiality and privacy requirements are SHOULD.  It seems to me
  that they ought to be "MUST implement" so that every implementation
  can be configured to make use of confidentiality and privacy.  An
  alternative would be "MUST implement" coupled with "SHOULD use when"
  statements, or "SHOULD" coupled with "geographic information MUST NOT
  be handled when confidentiality protection is not enabled."

[Ballot comment]
Overall this is a fine document. Several infelicities in the text might cause confusion:

1. In Section 3.2, "the service of non-repudiation implies after-the-fact" sounds like it should be "the service of non-repudiation applies after-the-fact" but instead the authors seem to mean that "the service of non-repudiation implies that the attack occurs after the fact" or somesuch.

2. In Section 3.3, "can all contribute to key management issues" could be construed as contributing to important or critical ("key") issues related to network management, not as "complicating the operations of key management" as in the previous paragraph; I suggest repeating the previously-used phrasing.

There are also several unfortunate typographical errors (e.g., "fundament" instead of "fundamental" in Section 3.4, "undue utilization of exhaustion" instead of "undue utilization or exhaustion" in Section 4.3.4, "any device local or remote" instead of "any local or remote device" in Section 5.1.5, "compliment" instead of "complement" in Section 6.1, "aimed the manipulation" instead of "aimed at the manipulation" in Section 6.5).

With regard to Denial of Service (DoS) in Section 4.3.3, please add a reference to RFC 4732.

Please provide informative references for OSPF and ISIS in Section 5.2.5.

In Section 6.1, is uppercase "MAY" meant in the text "new ciphering key may therefore be concurrently generated or updated"?

In Section 6.4, is uppercase "MUST" meant in the text "a LLN must include a process for key and credential distribution"?

In Section 6.4, is uppercase "SHOULD" meant in the text Correspondingly, the routing protocol(s) specified by the ROLL Working Group should assume that the system affords key management mechanisms consistent with the guidelines given in [RFC4107]"?

In Section 6.5, is uppercase "SHOULD" meant in the text "  As routing is one component of a LLN system, the actual strength of the security services afforded to it should be made to conform to each system's security policy"?

(And so on; in general, I suggest that the authors check all lowercase keywords throughout Section 6.)

State changed to In Last Call from Last Call Requested.

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 Framework 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 Framework for Routing over Low Power and Lossy Networks'
  as an 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 2010-12-30. 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.

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

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

State changed to AD Evaluation::Revised ID Needed from AD Evaluation.
AD Evaluation

======

Hi,

I have performed an AD review of your draft.

Don't panic!

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

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

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

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

Thanks for the work,
Adrian

---

idnits gives two warnings about references:

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

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

---

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

---

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

---

Section 3.2

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

s/on/on a/

---

Section 3.2

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

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

---

Section 3.2

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

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

---

Section 3.2

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

"those" what?

Suggest...

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

---

Section 3.2

Non-repudiation

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

That analysis is fine.

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

---

Section 3.3

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

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

---

Section 3.3

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

s/Lln/LLN/

---

Section 3.3

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

---

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

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

Proto-write-up for draft-ietf-roll-security-framework-02
Intended status : Informational Track

> (1.a)  Who is the Document Shepherd for this document?  Has the
>        Document Shepherd personally reviewed this version of the
>        document and, in particular, does he or she believe this
>        version is ready for forwarding to the IESG for publication?

JP Vasseur is the document shepherd.
He has personally reviewed the document and believes it is ready for
forwarding to the IESG for publication.

> (1.b)  Has the document had adequate review both from key WG members
>        and from key non-WG members?  Does the Document Shepherd have
>        any concerns about the depth or breadth of the reviews that
>        have been performed?

The I-D has been stable for some time.
The document got feed-back from few individuals, shepherded chair and the
technology advisor on security for the Working Group. Few comments have
been made on the mailing list during WG Last Call and addressed in this
revision.

> (1.c)  Does the Document Shepherd have concerns that the document
>        needs more review from a particular or broader perspective,
>        e.g., security, operational complexity, someone familiar with
>        AAA, internationalization or XML?

No concerns.

> (1.d)  Does the Document Shepherd have any specific concerns or
>        issues 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.  Has an IPR disclosure related to this document
>        been filed?  If so, please include a reference to the
>        disclosure and summarize the WG discussion and conclusion on
>        this issue.

The document is sound.

> (1.e)  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.

> (1.f)  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
>        entered into the ID Tracker.)

No threats. No discontent.

> (1.g)  Has the Document Shepherd personally verified that the
>        document satisfies all ID nits?  (See
>        http://www.ietf.org/ID-Checklist.html and
>        http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
>        not enough; this check needs to be thorough.  Has the document
>        met all formal review criteria it needs to, such as the MIB
>        Doctor, media type and URI type reviews?

Checks have been made. No Errors. Just few comments.

> (1.h)  Has the document split its references into normative and
>        informative?  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
>        strategy for their completion?  Are there normative references
>        that are downward references, as described in [RFC3967]?  If
>        so, list these downward references to support the Area
>        Director in the Last Call procedure for them [RFC3967].

References split has been done.

> (1.i)  Has the Document Shepherd verified that the document IANA
>        consideration section exists and is consistent with the body
>        of the document?  If the document specifies protocol
>        extensions, are reservations requested in appropriate IANA
>        registries?  Are the IANA registries clearly identified?  If
>        the document creates a new registry, does it define the
>        proposed initial contents of the registry and an allocation
>        procedure for future registrations?  Does it suggest a
>        reasonable name for the new registry?  See [RFC2434].  If the
>        document describes an Expert Review process has Shepherd
>        conferred with the Responsible Area Director so that the IESG
>        can appoint the needed Expert during the IESG Evaluation?

This document does not require any IANA action.

> (1.j)  Has the Document Shepherd verified that sections of the
>        document that are written in a formal language, such as XML
>        code, BNF rules, MIB definitions, etc., validate correctly in
>        an automated checker?

No such formal language is used.

> (1.k)  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.                   
  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.  The utility of this framework is demonstrated
  with an application to IPv6 Routing Protocol for Low Power and Lossy
  Networks (RPL) [I-D.ietf-roll-rpl].
>        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?

No discontent.

>        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 document is an informational framework.