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

Charles Perkins <charliep@lupinlodge.com> Wed, 18 August 2021 20:28 UTC

Return-Path: <charliep@lupinlodge.com>
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 B4FDB3A1C6A; Wed, 18 Aug 2021 13:28:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lupinlodge.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 UZxk5rcOQVkJ; Wed, 18 Aug 2021 13:28:28 -0700 (PDT)
Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [146.66.121.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A243B3A1C66; Wed, 18 Aug 2021 13:28:27 -0700 (PDT)
Received: from 246.206.208.35.bc.googleusercontent.com ([35.208.206.246] helo=giowm1055.siteground.biz) by se16.mailspamprotection.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <charliep@lupinlodge.com>) id 1mGSAe-0006qT-VM; Wed, 18 Aug 2021 15:28:24 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lupinlodge.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=x4l+UmfpyIqXfSqeVNgFpCPHss6KVGEmcgNNxtGs2Jk=; b=nJ6/9lfWWiU4EVNtHlaY1as0Ox Y8eUWdkNWHcpzrpy0kH8+Jaf4aESQEUz0UyykATmEu1150tWtCigqHajMTqZymfNkRMhBWBt+9w1X Wot8r5iH4OOyBdJp8UH4BLyxB/8BbGEDsLJO2KGqYKy1EAbtRYSZqbSfNqm1pRjHlCKk=;
Received: from [99.51.72.196] (port=52040 helo=[192.168.1.72]) by giowm1055.siteground.biz with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90-.1) (envelope-from <charliep@lupinlodge.com>) id 1mGSAe-000PGc-G8; Wed, 18 Aug 2021 20:28:20 +0000
To: Roman Danyliw <rdd@cert.org>, Routing Over Low power and Lossy networks <roll@ietf.org>, The IESG <iesg@ietf.org>
Cc: roll-chairs@ietf.org, mariainesrobles@googlemail.com, draft-ietf-roll-aodv-rpl@ietf.org
References: <161904623841.17653.13314629547868546211@ietfa.amsl.com>
From: Charles Perkins <charliep@lupinlodge.com>
Message-ID: <c5de8cf9-dd5d-cfd1-50d6-c0368d3762f0@lupinlodge.com>
Date: Wed, 18 Aug 2021 13:28:18 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <161904623841.17653.13314629547868546211@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: 35.208.206.246
X-SpamExperts-Domain: giowm1055.siteground.biz
X-SpamExperts-Username: 35.208.206.246
Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.208.206.246@giowm1055.siteground.biz
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.22)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9MKawy7XFKHdYLzfNa8DroPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5w7eqjV3umHXtZAfna397uT3Y6eSugsHMsWGw2POxshfUXy Uvr/ef/b2Eaz1j+xAOIG18GTzjJsSc7K2nOvm/XIETTZmou68uehA+IInhf6t7vDKRSeOy6sWF/5 dB1Kd4gzKQSavIsH4FUptcg4aK0N2VX+xIg0zhdLWAAqqCgWjaav0zW30NAlS7H9Jl9uSg1Z8Dxg G024zvkvsPJPT+VLMbcL5Znwe7iJe4Fg4yFmCSamJpeyEBQavbztVZ2TQzHmsmTsvjKn5rpVYfvw KPaKBGZ7bWHrTmjPEyoSRPRM5jjau8WIqoQoBbCB+7U9IDjaGQj5hQ0a97qLMrIaOR/IfYYhYqV8 k2MbRzeqSn5PuqgnjnNlBx79SYm9UuqYBXf3RXRzW9BocnzEvP3JtZgPfDEDcaKbczMwEis6t81t LoPAgTtUp75uqlx0KezvZHVJxeokEB3D0cxNTmDQAFR2DU9dLcpnr9FBGrchBzrBPRb2lVZ5tHai 5LkYXOEfjG6jztf7q0tqiKlISwggQuJ/+3ZqVB9RZAbQZJCobpUN//xEyVOZcJoJjrk0zpYb4vJA UEzw3S7Xr+3TrSAj4PCqa/x/wFQ2KDOoL0xbfAntwhWOw68b1vmRQ0fnVdIRRnNQvGCM7BBgrfUw QxCkabjUBDliz59Uzc74wyJaSDaT7OWBOXp8nHKe0R+FkIqN7hmBtbNllNMx9TX2yujvcQPoLv/5 85O+pWpOKIzg2yRxxDohWQvZrl8KYYjZj3Z7dAYvBoCzoxYBqLFgKTOKsyPbicD8e4duLeJKOT0U F79lbBqZR3KVQgqF/fPYYAfEfsjazqTD2gzNWgm7xgc6tVOA0HlkTt2NzkjOo8V++WAc/m6u2VZN vpNC2K41iYX23xZr6uP2UZAoFUB4WERHhxhclvwcpb1cjd9a+x9UVX6tlteOfXW9bOs5Y5oTKauz de1PJQcrCIAhqqJ7s6gdsDKnvKbq2Hnj1jge+cx4Kkll92sBaeNhDNYRTDFz49AJRRp+upmQcGbf VfpgQ0NSnqI4metYYgpdIfmCQr9qpmapsJyTHT/JBHLE0nM++24N+wpXosHFbEXtOMAWDaVXMRJ5 QZgwQAQ9NfskToW8laQ6TRPUaZyO2NbJhrfRU4/YgA3Xc4l5oeyLcwgJaO/AFuv91p5nQnG6A8RK fCGGEuMSqGNMzlbYmI3rrDIXGJnzGtawSQaXsZSfLy09ymyq5ov8FyrtVW4KaRSURqFyxA+5h7jO +dcyLACE2rpRco6OnojGhfFCfN1MNGC8/7MK1SfSUinNsb7GqeqHDjHdOLO0qQ==
X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Qag-JUlcVjqXduiequFH9oQ9eNs>
X-Mailman-Approved-At: Wed, 18 Aug 2021 23:29:07 -0700
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 <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Aug 2021 20:28:34 -0000

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