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

[Just moving this up the queue.   Thanks!]

On August 18, 2021 at 4:56:46 PM, Charles Perkins (charliep@lupinlodge.com)
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
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll