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

[Alvaro Retana <[e-mail]>]

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/