From nobody Thu Sep 16 06:30:21 2021 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478783A2912; Thu, 16 Sep 2021 06:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I9sZklzFJVgM; Thu, 16 Sep 2021 06:30:08 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5ACB03A291C; Thu, 16 Sep 2021 06:30:08 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id h17so16845668edj.6; Thu, 16 Sep 2021 06:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=+gxfPZH9cCJRZNBHvqDY7J4onSVI92eZi17jCQvO0Bk=; b=M2RyL/O1FsJWlrgwNvfJp65gF/lRgb4vWXS934ihvhTGBLco2e5vtgtojHe6KAwzST F0+xjUG3CHKuNxgRBfjcCbHPhe0IEsH7HGSOjo8SajMeHHzrNb7gZhwM4dwwj7eE5Tld 3mQ3eCZ2V/sJ6V9NBB79zzv8fkQXq2TiqL2eKGD+QTHk2dEBYxfmEGEgw3YXWjpciJ9Z VJTP7b2rqjjyWUVXuox250KSoQXLXVWKNQwg8WPcewm3YDKQiFD4I4xH1dWDGRgRZ0y/ W4luhXa47joZ+gb08Jg1ShgUm+AkSf40+fd3Xg6MfMmorNutFP0Ztiuwz4Ca79PyyEsM b9Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=+gxfPZH9cCJRZNBHvqDY7J4onSVI92eZi17jCQvO0Bk=; b=kZ3Xs6Lf7u51lRMwp/dQbexPXTshw9eESM5OQ93u+5Mjhuehrfd2CjcPP6PXMt2zlK yC0WJCPB0SjAJo3tlXPnHM6QZXjyzPBwsaKFsbruYoKe5sTXbxIMDSUqON22cr/DPl+S lRn9u4WBlOZ49u8ax4pnPruRQAGQ/YGBGccdTnYZVl4mFRae6ORHFQ+OGNplN2ruE56w sTyIRpgG6F94kZbMFPx+xc4BKG+sIFHxglF4vfyw2mZKWjzQakDlSN9qr49TzKmGYj9a LDtr58kEwKTEJe/oiVaPFceZIddF4GscgYb5w1SdZqyWg49pi7LU9FIVUzQ2yos6/73B hhJw== X-Gm-Message-State: AOAM5320dBBRh6s3EL9L6wCTTGkO8NiHN+cVQdWBiQSxB1KSwY1BUbuG 8305MSPMU4hSs3Gqmp92FGWjNCLo+OPs7kke/YQ= X-Google-Smtp-Source: ABdhPJwPk6OFEx5ueUuH9odoJ9+2YYYkhfgSubdRS8IApvX7QzBu1DcQljrrm7QowWFJQoTLvXF5MTcXAzIWj6IIn24= X-Received: by 2002:a17:906:c251:: with SMTP id bl17mr6099750ejb.219.1631799004924; Thu, 16 Sep 2021 06:30:04 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 16 Sep 2021 06:30:04 -0700 From: Alvaro Retana In-Reply-To: References: <161904623841.17653.13314629547868546211@ietfa.amsl.com> MIME-Version: 1.0 Date: Thu, 16 Sep 2021 06:30:04 -0700 Message-ID: To: Charles Perkins , Roman Danyliw , Routing Over Low power and Lossy networks , The IESG Cc: roll-chairs@ietf.org, mariainesrobles@googlemail.com, draft-ietf-roll-aodv-rpl@ietf.org Content-Type: multipart/alternative; boundary="000000000000088f8905cc1cd047" Archived-At: Subject: Re: [Roll] Roman Danyliw's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Sep 2021 13:30:15 -0000 --000000000000088f8905cc1cd047 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [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=E2=80=99s DISUSS. My feedback are also around clarifyi= ng 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=E2=80=99t 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=E2=80=99t there be an RPL configuration= which > doesn=E2=80=99t 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=E2=80=99s DISUSS. My feedback are also around clarifyin= g what > AODV-RPL inherits from RPL. > > ** Section 10. Per =E2=80=9CIn general, the security considerations for t= he operation > of AODV-RPL are similar to those for the operation of RPL=E2=80=9D, to be= clear do all > of the considerations from RFC6550 apply? The caveat of =E2=80=9CIn gener= al =E2=80=A6=E2=80=9D doesn=E2=80=99t > 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 =E2=80=9CA router can join a temporary DAG =E2=80=A6 o= nly if it can > support the Security Configuration in use, which also specifies the key I use=E2=80=9D: > > -- Is =E2=80=9CSecurity Configuration=E2=80=9D 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=E2=80=99t there be an RPL configuration whi= ch doesn=E2=80=99t > use secure join (i.e., =E2=80=9Cunsecured mode=E2=80=9D per Section 10.1 = of RFC6550)? > > ** Section 10. This section introduces a new acronym =E2=80=9CP2P-RPL=E2= =80=9D not used in any > other part of the document > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --000000000000088f8905cc1cd047 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
[Jus= t moving this up the queue. =C2=A0 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 t= o =20
your comments.

Regarding the following:

>=C2=A0 Roman Danyliw Discuss
> Discuss (2021-04-21)

> ** Section 10

>=C2=A0=C2=A0=C2=A0 If a rogue router knows the key for the Securit= y Configuration in
>=C2=A0=C2=A0=C2=A0 use, it can join the secure AODV-RPL route disc= overy and cause
>=C2=A0=C2=A0=C2=A0 various types of damage.=C2=A0 Such a rogue rou= ter could advertise false
>=C2=A0=C2=A0=C2=A0 information in its DIOs in order to include its= elf in the discovered
>=C2=A0=C2=A0=C2=A0 route(s).=C2=A0 It could generate bogus RREQ-DI= O, and RREP-DIO messages
>=C2=A0=C2=A0=C2=A0 carrying bad routes or maliciously modify genui= ne RREP-DIO messages
>=C2=A0=C2=A0=C2=A0 it receives.=C2=A0 A rogue router acting as the= OrigNode could launch
>=C2=A0=C2=A0=C2=A0 denial-of-service attacks against the LLN deplo= yment by initiating
>=C2=A0=C2=A0=C2=A0 fake AODV-RPL route discoveries.=C2=A0 In this = type of scenario, RPL's
>=C2=A0=C2=A0=C2=A0 preinstalled mode of operation, where the key t= o use for a P2P-RPL
>=C2=A0=C2=A0=C2=A0 route discovery is preinstalled, SHOULD be used= .

> Can the normative language in the last sentence please be clarifi= ed.=C2=A0 The
> entire paragraph prior is describing the behavior of the attacker= .=C2=A0 =20
Is this
> last sentence is suggesting a particular mode of operation?=C2=A0= If the =20
router
> is rogue, how is the fact that the key is pre-installed inhibit t= he =20
behavior
> of the attacker?

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


> Comment (2021-04-21)

> ** I support John=E2=80=99s DISUSS.=C2=A0 My feedback are also ar= ound clarifying what
> AODV-RPL inherits from RPL.

Our response to John addresses this comment.

> ** Section 10.=C2=A0 Per "In general, the security considera= tions for the
> operation of AODV-RPL are similar to those for the operation of R= PL",
> to be clear do all of the considerations from RFC6550 apply? The = caveat
> of "In general "" doesn=E2=80=99t necessarily sugg= est that to me.

"In general" needs to be deleted.=C2=A0 We will identify whic= h considerations do
not apply, if any.=C2=A0 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.=C2=A0 Unless AODV-RPL is upgrading the requirement= s of RPL, I
> believe all of the referenced security framework is optional. I w= ould
> recommend being clear on that:

> OLD:
> Sections 6.1 and 10
>=C2=A0=C2=A0=C2=A0 of [RFC6550] describe RPL's security framew= ork, which provides data
>=C2=A0=C2=A0=C2=A0 confidentiality, authentication, replay protect= ion, and delay
>=C2=A0=C2=A0=C2=A0 protection services.

> NEW:
> Sections 6.1 and 10 of [RFC6550] describe RPL's optional secu= rity
> framework, which AODV-RPL rely on to provides data confidentialit= y,
> authentication, replay protection, and delay protection services.

Thanks for the text.


> ** Section 10.=C2=A0 Per=C2=A0 "A router can join a temporar= y DAG " only if it
> can support the Security Configuration in use, which also specifi= es
> the key I use":

> -- Is "Security Configuration" a term of art in RPL to = be capitalized?
>=C2=A0 I'm not sure if this is editorial feedback or a referen= ce to some RPL
> mechanism.

"Security Configuration" should not have been capitalized.

> -- Is this section referring to the processes described in Sectio= n 10.2
> of RFC6550?=C2=A0 I ask because couldn=E2=80=99t there be an RPL = configuration which
> doesn=E2=80=99t use secure join (i.e., "unsecured mode"= per Section 10.1 of
> RFC6550)?

The security configuration refers to Section 6.1 of RFC6550 entitled &q= uot;RPL
Security Fields" for configuring various security variants.=C2=A0 = Other RPL
security configurations might not use secure join.=C2=A0 During AODV-RP= L 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 =20
support
the security configuration in use, which also specifies the key in use.


> ** Section 10.=C2=A0 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.ht= ml
> 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 disc= overed
> route(s). It could generate bogus RREQ-DIO, and RREP-DIO mess= ages
> carrying bad routes or maliciously modify genuine RREP-DIO mes= sages
> it receives. A rogue router acting as the OrigNode could laun= ch
> denial-of-service attacks against the LLN deployment by initia= ting
> fake AODV-RPL route discoveries. In this type of scenario, RP= L'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 clarifie= d. The
> entire paragraph prior is describing the behavior of the attacker.= Is this
> last sentence is suggesting a particular mode of operation? If th= e router is
> rogue, how is the fact that the key is pre-installed inhibit the b= ehavior of
> the attacker?
>
>
> ------------------------------------------------------------------= ----
> COMMENT:
> ------------------------------------------------------------------= ----
>
> ** I support John=E2=80=99s DISUSS. My feedback are also around c= larifying what
> AODV-RPL inherits from RPL.
>
> ** Section 10. Per =E2=80=9CIn general, the security consideratio= ns for the operation
> of AODV-RPL are similar to those for the operation of RPL=E2=80=9D= , to be clear do all
> of the considerations from RFC6550 apply? The caveat of =E2=80=9C= In general =E2=80=A6=E2=80=9D doesn=E2=80=99t
> necessarily suggest that to me.
>
> ** Section 10. Unless AODV-RPL is upgrading the requirements of R= PL, I believe
> all of the referenced security framework is optional. I would rec= ommend being
> clear on that:
>
> OLD:
> Sections 6.1 and 10
> of [RFC6550] describe RPL's security framework, which prov= ides data
> confidentiality, authentication, replay protection, and delay
> protection services.
>
> NEW:
> Sections 6.1 and 10 of [RFC6550] describe RPL's optional secur= ity framework,
> which AODV-RPL rely on to provides data confidentiality, authentic= ation, replay
> protection, and delay protection services.
>
> ** Section 10. Per =E2=80=9CA router can join a temporary DAG = =E2=80=A6 only if it can
> support the Security Configuration in use, which also specifies th= e key I use=E2=80=9D:
>
> -- Is =E2=80=9CSecurity Configuration=E2=80=9D a term of art in RP= L to be capitalized? I'm not
> sure if this is editorial feedback or a reference to some RPL mech= anism.
>
> -- Is this section referring to the processes described in Section= 10.2 of
> RFC6550? I ask because couldn=E2=80=99t there be an RPL configura= tion which doesn=E2=80=99t
> use secure join (i.e., =E2=80=9Cunsecured mode=E2=80=9D per Sectio= n 10.1 of RFC6550)?
>
> ** Section 10. This section introduces a new acronym =E2=80=9CP2P= -RPL=E2=80=9D not used in any
> other part of the document
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www= .ietf.org/mailman/listinfo/roll

<= /body> --000000000000088f8905cc1cd047--