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

[Charles Perkins <[e-mail]>]

Hello Roman,

Please excuse the unusually long delay it has taken for us to respond to 
your comments.

Regarding the following:

 >  Roman Danyliw Discuss
 > Discuss (2021-04-21)

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

We are just referring to normative behavior in a published RFC.  It is not
the purpose of AODV-RPL to develop new security mechanisms, and so we 
rely on
existing specification.  The vulnerability is not new or specific to 
AODV-RPL.


 > Comment (2021-04-21)

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

Our response to John addresses this comment.

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

"In general" needs to be deleted.  We will identify which considerations do
not apply, if any.  Since the routing is point-to-point instead of only
star-shaped, AODV-RPL may have other security threats to be considered
in addition to RPL security considerations.

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

Thanks for the text.


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

"Security Configuration" should not have been capitalized.

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

The security configuration refers to Section 6.1 of RFC6550 entitled "RPL
Security Fields" for configuring various security variants.  Other RPL
security configurations might not use secure join.  During AODV-RPL route
discovey, a router can join a temporary DAG created with any of the
security modes of operation per Section 10.1 of RFC6550.
In modes other than "unsecured" mode, a router can join only if it can 
support
the security configuration in use, which also specifies the key in use.


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

That terminology is not needed at all, and is to be deleted.

Regards,
Charlie P.

On 4/21/2021 4:03 PM, Roman Danyliw via Datatracker wrote:
> 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
>
>
>
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll