[Roll] Roman Danyliw's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-roll-aodv-rpl-10: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Section 10

If a rogue router knows the key for the Security Configuration in
   use, it can join the secure AODV-RPL route discovery and cause
   various types of damage.  Such a rogue router could advertise false
   information in its DIOs in order to include itself in the discovered
   route(s).  It could generate bogus RREQ-DIO, and RREP-DIO messages
   carrying bad routes or maliciously modify genuine RREP-DIO messages
   it receives.  A rogue router acting as the OrigNode could launch
   denial-of-service attacks against the LLN deployment by initiating
   fake AODV-RPL route discoveries.  In this type of scenario, RPL's
   preinstalled mode of operation, where the key to use for a P2P-RPL
   route discovery is preinstalled, SHOULD be used.

Can the normative language in the last sentence please be clarified.  The
entire paragraph prior is describing the behavior of the attacker.  Is this
last sentence is suggesting a particular mode of operation?  If the router is
rogue, how is the fact that the key is pre-installed inhibit the behavior of
the attacker?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** I support John’s DISUSS.  My feedback are also around clarifying what
AODV-RPL inherits from RPL.

** Section 10.  Per “In general, the security considerations for the operation
of AODV-RPL are similar to those for the operation of RPL”, to be clear do all
of the considerations from RFC6550 apply?  The caveat of “In general …” doesn’t
necessarily suggest that to me.

** Section 10.  Unless AODV-RPL is upgrading the requirements of RPL, I believe
all of the referenced security framework is optional.  I would recommend being
clear on that:

OLD:
Sections 6.1 and 10
   of [RFC6550] describe RPL's security framework, which provides data
   confidentiality, authentication, replay protection, and delay
   protection services.

NEW:
Sections 6.1 and 10 of [RFC6550] describe RPL's optional security framework,
which AODV-RPL rely on to provides data confidentiality, authentication, replay
protection, and delay protection services.

** Section 10.  Per  “A router can join a temporary DAG … only if it can
support the Security Configuration in use, which also specifies the key I use”:

-- Is “Security Configuration” a term of art in RPL to be capitalized?  I'm not
sure if this is editorial feedback or a reference to some RPL mechanism.

-- Is this section referring to the processes described in Section 10.2 of
RFC6550?  I ask because couldn’t there be an RPL configuration which doesn’t
use secure join (i.e., “unsecured mode” per Section 10.1 of RFC6550)?

** Section 10.  This section introduces a new acronym “P2P-RPL” not used in any
other part of the document