Re: [Roll] Last Comments about draft-ietf-roll-aodv-rpl-09

Charlie Perkins <charles.perkins@earthlink.net> Sun, 28 March 2021 16:58 UTC

Return-Path: <charles.perkins@earthlink.net>
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 6E3A63A1BDE; Sun, 28 Mar 2021 09:58:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, RCVD_IN_MSPIKE_H2=-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 (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net
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 nUxQjocfbxp9; Sun, 28 Mar 2021 09:58:40 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) (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 AE9053A2112; Sun, 28 Mar 2021 09:58:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; s=dk12062016; t=1616950720; bh=UrZUHE9yKHeGh7IvHfjWc2eTHD9moCzLj2Tq qc8XcU0=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=cUU9q25m9IC9uXjs2mV4FALaJld8N1dAjsTppBZReIAnAr DIYkT5qkH5grmeqvqZiUthjYlTdOTvc85HfveCD7W30F2kIGDc70tnI/Loge8T9jxwM wC+rHe5y19Y+67lGlBJodhdNLy28LLi8/AEKgBKA1aJwWjBcuFfUFcnLi9ybMpgPQ5h /Qw6d4UEcWal6qCcMXasXBcBs/5R7V3+4rPTBipR5nQJIgy8G2aYIv/n6NLbwRRlKhc uYg9ZKyeR5NHzm7uABbevYaV8g783Cop0IMQwpPqjY8AXKFF4IuXJrP0Sgus83ZRaKH fR/Y2vlZXaDeA1eo2tC3xNYXadzA==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016; d=earthlink.net; b=rJuH78X9glDatiGcFC159NUlObl8BYFX6Id0ZXxiBMFiTZC/hHEWzQXeWDPlIE8YwUfF8neNeBiUETaSil7btuwrBBXXoUip8iZMj7JNUNqtCKDasBWLKQqpjDm3SGzJ9UE0wJ/qVUHafs9eAnZuqoOhXMSWDcqCkTonZLij7dy/c41Exq/mjslMBoZ1F8oKHcYW+hWIEycqYlKEm6W1h2n9iJXFm/rGF/NLcLNb0F7OnicwxYq6aFNRTgNk5OWpVS5kVR8zxpLC4ssU0pO8Lk42EkcyphuAsMru+x7BFlNjXfTNH1Foir1MS0oOT34K/coz+Pd/5/CNhKbG8mmIOg==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [99.51.72.196] (helo=[192.168.1.72]) by elasmtp-curtail.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from <charles.perkins@earthlink.net>) id 1lQYkI-000E0o-7e; Sun, 28 Mar 2021 12:58:38 -0400
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: draft-ietf-roll-aodv-rpl@ietf.org, Ines Robles <mariainesrobles@googlemail.com>, roll-chairs@ietf.org, roll@ietf.org
References: <CAMMESswCqVExzWthP-bGcAdR7oEJNY5R2_CAh=sL3Ujk-pLPAQ@mail.gmail.com>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <3fca76f1-9672-a14f-0c07-3c1b3cf9d9e0@earthlink.net>
Date: Sun, 28 Mar 2021 09:58:37 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CAMMESswCqVExzWthP-bGcAdR7oEJNY5R2_CAh=sL3Ujk-pLPAQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956df8303b86ceddf554e812a1368aa72d976c3f49ffcfd52f0350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/hEn8VVJWi1UdKf-95_mZFtmiBBE>
Subject: Re: [Roll] Last Comments about draft-ietf-roll-aodv-rpl-09
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: Sun, 28 Mar 2021 16:58:45 -0000

Hello Alvaro,

I have followed your suggestions as mentioned below.

I believe the document would benefit if it mentioned that the current 
version protocol could be improved by specifying an authenticated mode 
of operation (analogous to what was described in RFC 6550).  It would 
not be *mandated* to use it - you are right that was not a good choice 
of words.  What would you suggest?

Naturally Yours,
Charlie P.


On 3/16/2021 2:34 PM, Alvaro Retana wrote:
> Charlie:
>
>
> Hi!  How are you?
>
> I've been looking at -09, and it looks like there are some changes
> that you mentioned in previous replies that are not included in this
> new version.  Also, I have a couple of comments left.
>
> You can address these along with other last call comments.  I'm
> starting the IETF Last Call.
>
> Thanks!
>
> Alvaro.
>
>
>
> (1) Both §4.1/§4.2 say that if there's more than one RREQ/RREP, then
> the message "SHOULD be dropped".  You had mentioned [1] that you would
> change these to "MUST".
>
>
> (2) I am not too happy with the last couple of sentences here (§10
> Security Considerations)...
>
> 930	   If a rogue router knows the key for the Security Configuration in
> 931	   use, it can join the secure AODV-RPL route discovery and cause
> 932	   various types of damage.  Such a rogue router could advertise false
> 933	   information in its DIOs in order to include itself in the discovered
> 934	   route(s).  It could generate bogus RREQ-DIO, and RREP-DIO messages
> 935	   carrying bad routes or maliciously modify genuine RREP-DIO messages
> 936	   it receives.  A rogue router acting as the OrigNode could launch
> 937	   denial-of-service attacks against the LLN deployment by initiating
> 938	   fake AODV-RPL route discoveries.  In this type of scenario, RPL's
> 939	   preinstalled mode of operation, where the key to use for a P2P-RPL
> 940	   route discovery is preinstalled, SHOULD be used.  If a future IETF
> 941	   document specifies the authenticated mode of operation as described
> 942	   in [RFC6550], then future AODV-RPL implementations SHOULD use the
> 943	   authenticated mode of operation.
>
> ...because the text is recommending what to do if a future document
> specifies an unknown (today) behavior.  I would feel better if we just
> eliminated the last sentence.
>
>
> (3) RFC6998 wasn't moved to be an Informative reference.
>
> (4) rfc7416 should also be moved to the Informative section.
>
>
>
> [1] https://mailarchive.ietf.org/arch/msg/roll/d0BQNFuZ7X-5wYpcT8nuORoeoeg/