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

[Roman Danyliw <[e-mail]>]

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 <[e-mail]> On Behalf Of Charles Perkins
> Sent: Wednesday, August 18, 2021 4:28 PM
> To: Roman Danyliw <[e-mail]>; Routing Over Low power and Lossy
> networks <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; draft-ietf-roll-aodv-
> [e-mail]
> 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  >
> 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