Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing
draft-ietf-6lowpan-routing-requirements-10

[Ballot discuss]
Updated based on -09.  I retained the numbering.

#5) Sec 5.4:  With regards to the 802.15.4 AES MAC based on AES.  The intro has:

Solutions may take into account
the specific features of IEEE 802.15.4 MAC layers.

but later it says:

Routing protocols need to define how this mechanism can be used to
obtain the intended security, either for the routing protocol
alone or in conjunction with the security used for the data.

The "may" and "need to" don't seem to line up.

Further, according to RFC 4919:

IEEE 802.15.4 mandates link-layer security based on AES

so why isn't this need to define /taking in to account a MUST?

In a nutshell it's not clear to me how the routing data is going to be secured.  MUST it be the IEEE mechanism, can it be something else that is WG defined, or can it be something already defined elsewhere in the IETF?

[Ballot discuss]
I am updating my Discuss in step with the -08 revision of this document.

---

I have updated this Discuss to specifically catch the remaining items raised by Dimitri Papadimitriou in his Routing Area Directorate review. Thanks for resolving many of the points so far.

1. Does reliable routing mean "reliable communication of routing PDU
  exchange" clarification would be appreciated?

  -> NOK (the term still used in qualifying transmission and protocol
      messaging). This could be further clarified

2. Are all RFD and FFD expected to be part of the same routing domain?

  -> NOK. Doesn't seem to be addressed.

---

Expanding my Discuss issue to try to make it more clearly actionable...

I wrote:

> The Mesh Under description appears to suggest that there is a
> requirement to build a routing system for MAC addresses (i.e. not for
> IP addresses). If this is a requirement it has been far too deeply
> hidden in this document. It needs to be brought out and examined more
> because with one notable exception, the IETF does not normally work
> with routing for non-IP addresses.
>
> Do you really want this requirement to remain hidden, or is there a need
> to bring it to the attention of the IEEE?

To be clear:
I am not asking for the mesh-under requirement to be removed (it is in the WG charter and should be in this document). I *am* asking for the mesh-under requirement to be made more visible and apparent in the document, and I am asking that the requirement should be directed to a body that might consider working on the solution (since requirements are no value if they are hidden or implicit, and are unlikely to be acted on unless they are clearly indicated to the SDO responsible for solutions work).

[Ballot comment]
I remain unhappy about the objective of this document within the IETF since it seems to be capturing requirements for routing in a 6lowpan that form a subset of the requirements already documented and addressed by the ROLL working group. Nevertheless, since my gripes are mainly about process, I am taking them out of my Discuss so that the document can proceed. I would still be happy to have it clarified to me how this document fits in with the ROLL effort.

[Ballot discuss]
I am updating my Discuss in step with the -07 revision of this document.

---

I am holding a Discuss until the Dimitri Papadimitriou indicates that the points raised in his Routing Area Directorate review have been resolved. The authors are in discussions with him.

---

The Mesh Under description appears to suggest that there is a
requirement to build a routing system for MAC addresses (i.e. not for
IP addresses). If this is a requirement it has been far too deeply
hidden in this document. It needs to be brought out and examined more
because with one notable exception, the IETF does not normally work
with routing for non-IP addresses.

Do you really want this requirement to remain hidden, or is there a need to bring it to the attention of the IEEE?

[Ballot discuss]
This is an updated discuss.  I retained the numbering.

#1) This is a DISCUSS-DISCUSS.  To be clear there's nothing for the authors to do at this time.

The charter indicates that the WG will develop:

  6. Produce "6LoWPAN Security Analysis" to define the threat model
    of 6LoWPANs, to document suitability of existing key management
    schemes and to discuss
    bootstrapping/installation/commissioning/setup issues. This
    document will be referenced from the "security considerations"
    of the other 6LoWPAN documents.  This document will be
    informational.

Shouldn't this document point to that document?  Is that document no longer going to be published?



#5) Sec 5.4:  With regards to the 802.15.4 AES MAC based on AES.  The intro has:

Solutions may take into account
the specific features of IEEE 802.15.4 MAC layers.

but later it says:

Routing protocols need to define how this mechanism can be used to
obtain the intended security, either for the routing protocol
alone or in conjunction with the security used for the data.

The "may" and "need to" don't seem to line up.

Further, according to RFC 4919:

IEEE 802.15.4 mandates link-layer security based on AES

so why isn't this need to define /taking in to account a MUST?

In a nutshell it's not clear to me how the routing data is going to be secured.  MUST it be the IEEE mechanism, can it be something else that is WG defined, or can it be something already defined elsewhere in the IETF?

[Ballot discuss]
1. I support the part of Adrian's DISCUSS concerning the need to coordinate and have this document reviewed by the ROLL WG. I note that the WG charter explicitly mentions working closely with ROLL.

2. I cannot see in the document any requirement related to the management of the nodes implementing 6lowpan routing. The charter talks about 'define the necessary security and management protocols and constructs for building 6LoWPAN networks- - is this covered in another document, or should it be covered here?

[Ballot discuss]
I agree with Adrian's DISCUSS.

I am particularly concerned with

"Here, 'Routing' is not equivalent to IP routing, but includes the functionalities of path computation and forwarding under the IP layer."

In the IETF "Routing" has a well known meaning, and if this document proposes something else, it needs a new term.

[Ballot discuss]
(1) This document seems to assume that a LoWPAN will be either Route Over or Mesh Under in its
entirety.  This is not an obvious result.  I would expect that a Mesh Under could live transparently
within a Route Over LoWPAN.  (Essentially, the ER in the Mesh Under LoWPAN from Figure 3
would be LoWPAN router in the Figure 2 Route Over network.)  If this scenario is realistic, the document should address any routing requirements that would be introduced (or note that no new requirements are established by the hybrid scenario.  [Note: it is not as clear to me whether a Route Over in a Mesh Under makes sense.]

(2) The term "node" seems to be used inconsistently within this document, and with respect to IEEE
802.15.4 and 6lowpan-nd.  For example, in figure 2 all components of a Route Over network are
labeled as edge routers, LoWPAN routers, or LoWPAN hosts.  Figure 3 labels several components
in a mesh under network as "mesh nodes", and the remaining components are Edge routers or
LoWPAN hosts.  The text that follows (last paragraph in 3.1) opens with a discussion of communication between nodes in different LoWPANs -shouldn't this include communication
between LoWPAN hosts?  The next sentence talks about nodes performing IP routing in the
Route Over case, but Figure 2 doesn't have "nodes". 

Note: I considered making this a comment, since it is editorial, but being consistent with these
terms is essential to understanding the document!

(3) The text in Figure 1 and section 3.2 is inconsistent.  (Figure 1 "shows the place of 6LoWPAN
routing in the entire network stack.")

From 3.2:
  In the simplest case for a Mesh Under where layer two forwarding can
  be performed without piggy-backing routing protocol information, the
  mesh-header defined in RFC 4944 [RFC4944] is sufficient, see
  Figure 5.

This implies that the 6LoWPAN routing could occur in the IEEE 802.15.4 MAC layer.  I realize
that ascii art has its limitations, but if that is correct a note in the accompanying text in section 3
would be helpful.

[Ballot discuss]
I have some significant concerns about this document. These cover
both process and techncial content.

---

These requirements have arrived very late in the cycle. The ROLL
working group has written four requirements documents (3 RFCs and
one on the RFC Editor Queue), and the RPL specification is nearing
completion. In fact, some of the rquirements in this document
actually reference the requirements published by the ROLL WG.

It is unclear how these requirements should be applied and whether
they are a subset of the rquirements already captured by the ROLL
working group or different in some way.

If the requirements have all been captured already, I suggest that
this document should become Historic. If the reuirements are "new"
to the work done by ROLL, then please see the next point.

---

The proto write-up says...

  On a [One?] single person, JP Vasseur, has indicated discontent
  with the document.  He seems to feel the document is unnecessary
  because, in his opinion, it overlaps with the ROLL WG work.  This
  document, though, is specific to 6lowpan and references the
  documents of ROLL.  ROLLs work is not specific to 6lowpan
  networks.

I note that the person expressing the concern is one of the co-chairs
of the ROLL working group.

The Abstract says...

  The purpose of this
  document is not to recommend specific solutions, but to provide
  general, layer-agnostic guidelines about the design of 6LoWPAN
  routing, which can lead to further analysis and protocol design.
  This document is intended as input to groups working on routing
  protocols relevant to 6LoWPAN, such as the IETF ROLL WG.

It is clear, therefore that, in the opinion of the 6lowpan working
gorup, this document does overlap with the work of the ROLL working
group.

The proto write-up does not show any signs of the document having
been discussed with the ROLL working group or within the Routing
Area more widely. I don't see any mention of the document on the                             
ROLL working group mailing list.

I find this expression that the ROLL working group is an intended
consumer of this document very strange when combined with the
disregard of the that working group's view of the document.

Furthermore, the 6lowpan charter says...

  6lowpan will work closely with the Routing Over Low power and
  Lossy networks (roll) working group which is developing IPv6
  routing solutions for low power and lossy networks (LLNs).

I do not see any demonstration of close working.

What actions have been taken to ensure that the content of this
document are understood by the ROLL working group and that the
details are relevant to the people developing routing protocol
solutions?

---

Section 1 (and again, Section 4) refers to a requirement for
"data-aware routing" without giving any description of this term.

The term is sometimes used to refer to the concept of routing packets
according to the data content of those packets. This is not consistent
with IP routing paradigms and would need to be brought out for full
discussion.

Potentially you mean something else by this term in which case you
really do need to define the term.

---

Section 3.2

It is not appropriate for an Informational requirements document to
take a position on which solutions my be adequate or to give PDU
specifications.

---

The document would have benefitted significantly from review in the
Routing Area. The Routing ADs asked Dimitri Papadimitriou to review
the document on behalf of the Routing Area Directorate. His comments
will be sent to the document authors under separate cover. Many of
his comments are very significant, and all would seriously improve
the document.

Please address the comments and update the document accordingly.

---

Requirement 8 says

  [R08] 6LoWPAN routing protocols SHOULD be reliable despite
  unresponsive nodes due to periodic hibernation.                                     

This needs to be clarified. What is "protocol reliability". Do you mean
that the protocol should exchange packets reliably, that the protocol
should be able to reliably find a path, or that the path found should
be reliabel?

---

Requirement 11 says

  [R11] The procedure of route repair and related control messages
  should not harm overall energy consumption from the routing
  protocols.

Why don't you use "SHOULD NOT"?

---

The Mesh Under description appears to suggest that there is a
requirement to build a routing system for MAC addresses (i.e. not for
IP addresses). If this is a requirement it has been far too deeply
hidden in this document. It needs to be brought out and examined more
because with one notable exception, the IETF does not normally work
with routing for non-IP addresses.

---

Requirement 17

  [R17] In case there are one or more nodes allocated for the specific
  role of local management, such a management node MAY take the role of
  keeping track of nodes within the area of the LoWPAN it takes
  responsibility for.

Is this a requirement on the routing protocol? It doesn't appear to be.

---

Requirement 18

  [R18] If the routing protocol functionality includes enabling IP
  multicast, then it may want to employ structure in the network for
  efficient distribution [I-D.ietf-manet-smf], such as Connected
  Dominating Sets (CDS), Multi-Point Relays (MPR), or relay points
  sending point-to-multipoint messages in unicast messages instead of
  using link-layer multicast (broadcast).

Do you mean "MAY".

"may want to" seems like a very flimsy "requirement." Actually, the
paragraph looks like a solution in search of a requirement. Can you
turn this into a potential requirement, and leave the solution for
the solution documents?

---

Section 6 needs to make more clarity by separating the requirements
for security of the routing protocol, and the requirements of security
for end-to-end data that can be assisted by the routing protocol.

[Ballot comment]
Please review the secdir review in its totality.  I realize this came in late, but I think there
are a number of comments that would improve the document.  The review is available at:

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

[Ballot comment]
I have a few questions:

Section 4., paragraph 15:
>        *  Classes of Service:
>          For mixing applications of different criticality on one
>          LoWPAN, support of multiple classes of service may be required
>          in resource-constrained LoWPANs and may require a certain
>          degree of routing protocol overhead.

  I'm not sure I see why. QoS support typically involves end-to-end
  transport functions and more complex *queueing*, but not routing
  *protocol* overheads. Could you explain?


Section 4., paragraph 17:
>    b.  Node Parameters:

  Isn't queuing strategy and queue buffer size also a parameter?


Section 4., paragraph 21:
>        *  Traffic Pattern:
>          This parameter affects routing since highly loaded nodes
>          (either because they are the source of packets to be
>          transmitted or due to forwarding) may contribute to higher
>          delivery delays and may consume more energy than lightly
>          loaded nodes.  This applies to both data packets and routing
>          control messages.

  Again, I'm not sure I understand. Why does the volume of application
  data sent or received by some nodes affect the routing *protocol*?

[Ballot discuss]
#1) This is a DISCUSS-DISCUSS.  To be clear there's nothing for the authors to do at this time.

The charter indicates that the WG will develop:

  6. Produce "6LoWPAN Security Analysis" to define the threat model
    of 6LoWPANs, to document suitability of existing key management
    schemes and to discuss
    bootstrapping/installation/commissioning/setup issues. This
    document will be referenced from the "security considerations"
    of the other 6LoWPAN documents.  This document will be
    informational.

Shouldn't this document point to that document?  Is that document no longer going to be published?

#2) The Security Considerations point to RFC 4944 and that includes the [KW03] reference for attacks and counter measures for sensor networks.  Do these line up with the threats defined in RFC 4593?  Did the WG consider RFC 4593?  I don't have a copy of the [KW03] reference so it's hard for me to tell.

#3) Sec 5.4: What do you mean by secure delivery/transmission?  Does secure delivery/transmission encompass origin authentication, integrity, and confidentiality or some subset?  RFC 4919 only refers to confidentiality and integrity.  I think you should be explicit about what "secure delivery" means.

#4) Sec 5.4: Why isn't a MUST support secure delivery?  To me, SHOULD means the protocol might not support the option of secure delivery/transport.  That is a bad thing in my book.  If you make it MUST support then it's built-in when you need it.

#5) Sec 5.4:  With regards to the 802.15.4 AES MAC based on AES.  The intro has:

Solutions may take into account
the specific features of IEEE 802.15.4 MAC layers.

but later it says:

Routing protocols need to define how this mechanism can be used to
obtain the intended security, either for the routing protocol
alone or in conjunction with the security used for the data.

The "may" and "need to" don't seem to line up.

Further, according to RFC 4919:

IEEE 802.15.4 mandates link-layer security based on AES

so why isn't this need to define /taking in to account a MUST?

In a nutshell it's not clear to me how the routing data is going to be secured.  MUST it be the IEEE mechanism, can it be something else that is WG defined, or can it be something already defined elsewhere in the IETF?

In [R14],  I think you should delete the 2nd sentence from the requirements statement.

#6) Sec 5.4: In the security threats paragraph, it says:

  Neighbor Discovery in IEEE 802.15.4 links may be susceptible to
  threats as listed in RFC3756 [RFC3756].

Are they or aren't they?  If they are, then which ones apply?

#7) Sec 5.4: In the security threats paragraph, it says:

  Bootstrapping may also impose additional threats.

What are these threats?  How are they mitigated?

#8) The following is in Section 5.4:

  While there are applications which require very high security,
  such as in traffic control, other applications are less easily
  harmed by wrong node behavior, such as a home entertainment system.

I'd disagree with this statement.  Say an emergency broadcast system is in effect and it's supposed to telling me via my TV to duck and cover and it's not.  My point is I'm not sure you need this sentence.

#9) Sec 6: I think the first sentence is a little off.  Neither 4919 or 4944 have  a section 4.4 that talks about security considerations.  Did you mean:

OLD:

Security issues are described in Section 4.4 of the security considerations of RFC 4919 [RFC4919] and RFC 4944 [RFC4944] apply as well.

NEW:

Security issues are described in Section 5.4.  The security considerations in RFC 4919 [RFC4919] and RFC 4944 [RFC4944] apply as well.

[Ballot discuss]
#1) This is a DISCUSS-DISCUSS.  To be clear there's nothing for the authors to do at this time.

The charter indicates that the WG will develop:

  6. Produce "6LoWPAN Security Analysis" to define the threat model
    of 6LoWPANs, to document suitability of existing key management
    schemes and to discuss
    bootstrapping/installation/commissioning/setup issues. This
    document will be referenced from the "security considerations"
    of the other 6LoWPAN documents.  This document will be
    informational.

Shouldn't this document point to that document?  Is that document no longer going to be published?

#2) The Security Considerations point to RFC 4944 and that includes the [KW03] reference for attacks and counter measures for sensor networks.  Do these line up with the threats defined in RFC 4593?  Did the WG consider RFC 4593?  I don't have a copy of the [KW03] reference so it's hard for me to tell.

#3) Sec 5.4: What do you mean by secure delivery/transmission?  Does secure delivery/transmission encompass origin authentication, integrity, and confidentiality or some subset?  RFC 4919 only refers to confidentiality and integrity.  I think you should be explicit about what "secure delivery" means.

#4) Sec 5.4: Why isn't a MUST support secure delivery?  To me, SHOULD means the protocol might not support the option of secure delivery/transport.  That is a bad thing in my book.  If you make it MUST support then it's built-in when you need it.

#5) Sec 5.4:  With regards to the 802.15.4 AES MAC based on AES.  The intro has:

Solutions may take into account
the specific features of IEEE 802.15.4 MAC layers.

but later it says:

Routing protocols need to define how this mechanism can be used to
obtain the intended security, either for the routing protocol
alone or in conjunction with the security used for the data.

The "may" and "need to" don't seem to line up.

Further, according to RFC 4919:

IEEE 802.15.4 mandates link-layer security based on AES

so why isn't this need to define /taking in to account a MUST?

In a nutshell it's not clear to me how the routing data is going to be secured.  MUST it be the IEEE mechanism, can it be something else that is WG defined, or can it be something already defined elsewhere in the IETF?

In [R14],  I think you should delete the 2nd sentence from the requirements statement.

#6) Sec 5.4: In the security threats paragraph, it says:

  Neighbor Discovery in IEEE 802.15.4 links may be susceptible to
  threats as listed in RFC3756 [RFC3756].

Are they or aren't they?  If they are, then which ones apply?

#7) Sec 5.4: In the security threats paragraph, it says:

  Bootstrapping may also impose additional threats.

What are these threats?  How are they mitigated?

#8) The following is in Section 5.4:

  While there are applications which require very high security,
  such as in traffic control, other applications are less easily
  harmed by wrong node behavior, such as a home entertainment system.

I'd disagree with this statement.  Say an emergency broadcast system is in effect and it's supposed to telling me via my TV to duck and cover and it's not.  My point is I'm not sure you need this sentence.

#9) RFC 4919

#8) Sec 6: I think the first sentence is a little off.  Neither 4919 or 4944 have  a section 4.4 that talks about security considerations.  Did you mean:

OLD:

Security issues are described in Section 4.4 of the security considerations of RFC 4919 [RFC4919] and RFC 4944 [RFC4944] apply as well.

NEW:

Security issues are described in Section 5.4.  The security considerations in RFC 4919 [RFC4919] and RFC 4944 [RFC4944] apply as well.

[Ballot comment]
I am debating whether to make this a DISCUSS:

Should this document discuss ways to mitigate the threats in RFC 4593 (Generic Threats to Routing Protocols)?

  (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?

Geoff Mulligan is the document shepherd.  I have personally reviewed the
document and believe it is ready for publication as an Informational RFC.


  (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 document has undergone a thorough review by the 6lowpan WG
and I don't have concerns about the breadth of review.

  (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?

I don't think the document needs broader review.


  (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.

I'm not uncomfortable with any part of this document and I don't
have any specific concerns.  There has been no IPR disclosures
related to this document.  We have actually done several WGLC's
and the WG has reached consensus on this document.

  (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? 

There is strong consensus within the 6lowpan WG to publish this document.

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

On a single person, JP Vasseur, has indicated discontent with the
document.  He seems to feel the document is unnecessary because,
in his opinion, it overlaps with the ROLL WG work.  This
document, though, is specific to 6lowpan and references the
documents of ROLL.  ROLLs work is not specific to 6lowpan networks.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        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?

Just a nit about the date and the trust provision.

  (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].

Yes the has split normative and informative references.

  (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 [RFC5226]. 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?

The section exists.  There are no IANA actions.

  (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?

Not applicable

  (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

This document provides the problem statement and design space for
6LoWPAN routing.  It defines the routing requirements for 6LoWPAN
networks, considering the low-power and other particular
characteristics of the devices and links.  The purpose of this
document is not to recommend specific solutions, but to provide
general, layer-agnostic guidelines about the design of 6LoWPAN
routing, which can lead to further analysis and protocol design.

    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 completed WGLC.

    Document Quality

This document was well reviewed by the 6lowpan WG.