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

From: Alvaro Retana <[email-masked]>
Date: Thu, 16 Sep 2021 06:30:04 -0700

[Just moving this up the queue.   Thanks!]

On August 18, 2021 at 4:56:46 PM, Charles Perkins ([email-masked])
wrote:

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: Roman Danyliw <[email-masked]>
Date: Sat, 18 Sep 2021 21:28:32 +0000

Hi Charlie!

Now my turn to apologize for the long delay.  Thank you for the clarifications below and the changes in -11 to address the COMMENTs.  I've cleared my ballot.

Regards,
Roman

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Charles Perkins
> Sent: Wednesday, August 18, 2021 4:28 PM
> To: Roman Danyliw <[email-masked]>; Routing Over Low power and Lossy
> networks <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; draft-ietf-roll-aodv-
> [email-masked]
> Subject: Re: [Roll] Roman Danyliw's Discuss on draft-ietf-roll-aodv-rpl-10: (with
> DISCUSS and COMMENT)
> 
> 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  >
>  > ** 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  >
> >    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,  >
>  > ** 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":
> 
>  >  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)?
> 
> 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
> > 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?
> >
> >
> > ** 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
> > Sections 6.1 and 10 of [RFC6550] describe RPL's optional security framework,
> > 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
> > -- 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
> > ** Section 10.  This section introduces a new acronym “P2P-RPL” not used in
> any