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

From: Alvaro Retana <[email-masked]>
Date: Tue, 16 Mar 2021 14:34:14 -0700

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/

---

From: Charlie Perkins <[email-masked]>
Date: Sun, 28 Mar 2021 09:58:37 -0700

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.