[Roll] AD Review of draft-ietf-roll-aodv-rpl-08

[Alvaro Retana <[e-mail]>]

Dear authors:

This is an incremental review based on some of the changes and the new
text in this version.  Some of the comments are a followup to previous
comments, but there are also some new issues.


Thanks!

Alvaro.


[Line numbers from idnits.]

...
102	1.  Introduction
...
125	   AODV-RPL reuses and provides a natural extension to the core RPL
126	   functionality to support routes with birectional asymmetric links.
127	   It retains RPL's DODAG formation, RPL Instance and the associated
128	   Objective Function, trickle timers, and support for storing and non-
129	   storing modes.  AODV adds basic messages RREQ and RREP as part of RPL
130	   DIO (DODAG Information Object) control messages, and does not utilize
131	   the DAO message of RPL.  AODV-RPL specifies a new MOP running in a
132	   seperate instance dedicating to discover P2P routes, which may differ
133	   from the P2MP routes discoverable by native RPL.  AODV-RPL can be
134	   operated whether or not native RPL is running otherwise.

[nit] s/seperate instance dedicating/separate instance dedicated

[major] "AODV-RPL can be operated whether or not native RPL is running
otherwise."  If native RPL is also running in the LLN, it can learn
the same routes as the ones discovered through AODV-RPL.  Which route
should have preference, or is this a deployment issue and outside the
scope?

[major] If native RPL is already running in an LLN, how would AODV-RPL
be introduced in the network?  I'm thinking about §2/rfc5706.


136	2.  Terminology
...
144	   AODV
145	      Ad Hoc On-demand Distance Vector Routing[RFC3561].

[nit] s/Routing[RFC3561]/Routing [RFC3561]


...
422	4.3.  AODV-RPL Target Option
...
451	              Figure 3: Target option format for AODV-RPL MOP

[minor] s/Target option/ART Option (or AODV-RPL Target option)/g(almost)

There are some places where "target option" is used to refer to the
ART option, but without the extra qualification it may be confused
with the Target option in core RPL.  IOW, let's be painfully specific.



...
485	5.  Symmetric and Asymmetric Routes
...
539	   Appendix A describes an example method using the ETX and RSSI to
540	   estimate whether the link is symmetric in terms of link quality is
541	   given in using an averaging technique.

[minor] Please expand ETX/RSSI.


...
605	6.2.1.  General Processing
...
615	      If the S bit in the received RREQ-DIO is set to 1, the router MUST
616	      determine whether each direction of the link (by which the RREQ-
617	      DIO is received) satisfies the Objective Function.  In case that
618	      the downward (i.e. towards the TargNode) direction of the link
619	      does not satisfy the Objective Function, the link can't be used
620	      symmetrically, thus the S bit of the RREQ-DIO to be sent out MUST
621	      be set as 0.  If the S bit in the received RREQ-DIO is set to 0,
622	      the router MUST only check into the upward direction (towards the
623	      OrigNode) of the link.

[major] s/MUST only check/MUST determine...

You fixed the first occurrence of MUST check, but not the second.


625	      If the upward direction of the link can satisfy the Objective
626	      Function (defined in [RFC6551]), and the router's Rank would not
627	      exceed the MaxUseRank limit, the router joins the DODAG of the
628	      RREQ-Instance.  The router that transmitted the received RREQ-DIO
629	      is selected as the preferred parent.  Otherwise, if the Objective
630	      Function is not satisfied or the MaxUseRank limit is exceeded, the
631	      router MUST discard the received RREQ-DIO and MUST NOT join the
632	      DODAG.

[minor] "Objective Function (defined in [RFC6551])"   Put the
reference when OF is first used.


...
642	      If the H bit is set to 1, then the router (TargNode or
643	      intermediate) MUST build an upward route entry towards OrigNode
644	      which MUST include at least the following items: Source Address,
645	      InstanceID, Destination Address, Next Hop, Lifetime, and Sequence
646	      Number.  The Destination Address and the InstanceID respectively
647	      can be learned from the DODAGID and the RPLInstanceID of the RREQ-
648	      DIO, and the Source Address is the address used by the local
649	      router to send data to the OrigNode.  The Next Hop is the
650	      preferred parent.  The lifetime is set according to DODAG
651	      configuration (i.e., not the L bit) and can be extended when the
652	      route is actually used.  The sequence number represents the
653	      freshness of the route entry, and it is copied from the Orig SeqNo
654	      field of the RREQ option.  A route entry with the same source and
655	      destination address, same InstanceID, but stale sequence number,
656	      MUST be deleted.

[major] s/MUST build an upward route entry towards OrigNode which MUST
include at least the following items/MUST build an upward route entry
towards OrigNode which includes at least the following items


658	   Step 4:

660	      If the router is an intermediate router, then it transmits a RREQ-
661	      DIO via link-local multicast; if the H bit is set to 0, the
662	      intermediate router MUST include the address of the interface
663	      receiving the RREQ-DIO into the address vector..  Otherwise, if
664	      the router (i.e., TargNode) was not already associated with the
665	      RREQ-Instance, it prepares a RREP-DIO Section 6.3.  If, on the
666	      other hand TargNode was already associated with the RREQ-Instance,
667	      it takes no further action and does not send an RREP-DIO.

[nit] s/../.

[nit] s/Section 6.3./(Section 6.3).


...
764	6.4.  Receiving and Forwarding Route Reply
...
773	      If the S bit of the RREP-DIO is set to 0, the router MUST check
774	      the downward direction of the link (towards the TargNode) over
775	      which the RREP-DIO is received.  If the downward direction of the
776	      link can satisfy the Objective Function, and the router's Rank
777	      would not exceed the MaxRank limit, the router joins the DODAG of
778	      the RREP-Instance.  The router that transmitted the received RREP-
779	      DIO is selected as the preferred parent.  Afterwards, other RREP-
780	      DIO messages can be received.

[] s/the router MUST check.../the router MUST determine...satisfies

IOW, join the two sentences.


...
794	      If the H bit is set to 1, then the router (OrigNode or
795	      intermediate) MUST build a downward route entry.  The route entry
796	      MUST include at least the following items: OrigNode Address,
797	      InstanceID, TargNode Address as destination, Next Hop, Lifetime
798	      and Sequence Number.  For a symmetric route, the Next Hop in the
799	      route entry is the router from which the RREP-DIO is received.
800	      For an asymmetric route, the Next Hop is the preferred parent in
801	      the DODAG of RREQ-Instance.  The InstanceID in the route entry
802	      MUST be the original RPLInstanceID (after subtracting the Shift
803	      field value).  The source address is learned from the ART Option,
804	      and the destination address is learned from the DODAGID.  The
805	      lifetime is set according to DODAG configuration and can be
806	      extended when the route is actually used.  The sequence number
807	      represents the freshness of the route entry, and is copied from
808	      the Dest SeqNo field of the ART option of the RREP-DIO.  A route
809	      entry with same source and destination address, same InstanceID,
810	      but stale sequence number, SHOULD be deleted.

[major] s/MUST build a downward route entry.  The route entry MUST
include at least the following items/MUST build a downward route entry
towards TargNode which includes at least the following items

[minor] s/The lifetime is set according to DODAG configuration and can
be extended when the route is actually used./The lifetime is set
according to DODAG configuration (i.e., not the L bit) and can be
extended when the route is actually used.

[major] s/stale sequence number, SHOULD be deleted./stale sequence
number, MUST be deleted.


812	      If the H bit is set to 0, for an asymmetric route, an intermediate
813	      router MUST include the address of the interface receiving the
814	      RREP-DIO into the address vector; for a symmetric route, there is
815	      nothing to do in this step.

[minor] In §6.2.1 the part about H=0 was moved to Step 4.  Please do
the same here.


...
830	   Upon receiving a RREP-DIO, a router which already belongs to the
831	   RREQ-Instance SHOULD drop the RREP-DIO.

[minor] When it is ok to not drop it?  I'm assuming that there's no
harm in propagating the extra RREP, right?  IOW, there's no need for
MUST.



...
876	9.1.  New Mode of Operation: AODV-RPL

878	   IANA is asked to assign a new Mode of Operation, named "AODV-RPL" for
879	   Point-to-Point(P2P) hop-by-hop routing from the "Mode of Operation"
880	   Registry [RFC6550].

[major] The reference is not needed because even though the registry
was defined in rfc6550, the RFC is not the registry.

[major] A note should be added indicating that the number in
parenthesis is a suggestion.


882	              +-------------+---------------+---------------+
883	              |    Value    |  Description  |   Reference   |
884	              +-------------+---------------+---------------+
885	              |   TBD1 (5)  |   AODV-RPL    | This document |
886	              +-------------+---------------+---------------+

888	                        Figure 6: Mode of Operation

890	9.2.  AODV-RPL Options: RREQ, RREP, and Target

892	   IANA is asked to assign three new AODV-RPL options "RREQ", "RREP" and
893	   "ART", as described in Figure 7 from the "RPL Control Message
894	   Options" Registry [RFC6550].

[major] The reference is not needed because even though the registry
was defined in rfc6550, the RFC is not the registry.

[major] A note should be added indicating that the number in
parenthesis is a suggestion.


896	          +-------------+------------------------+---------------+
897	          |    Value    |        Meaning         |   Reference   |
898	          +-------------+------------------------+---------------+
899	          | TBD2 (0x0A) |      RREQ Option       | This document |
900	          +-------------+------------------------+---------------+
901	          | TBD3 (0x0B) |      RREP Option       | This document |
902	          +-------------+------------------------+---------------+
903	          | TBD4 (0x0C) |       ART Option       | This document |
904	          +-------------+------------------------+---------------+

[major] 0x0a is already assigned to rfc6997!


906	                        Figure 7: AODV-RPL Options

908	10.  Security Considerations

910	   In general, the security considerations for the operation of AODV-RPL
911	   are similar to those for the operation of RPL (as described in
912	   Section 19 of the RPL specification [RFC6550]).  Sections 6.1 and 10
913	   of [RFC6550] describe RPL's security framework, which provides data
914	   confidentiality, authentication, replay protection, and delay
915	   protection services.

[] It may be a god idea to also point at rfc7416 as an Informative reference.


...
924	   If a rogue router knows the key for the Security Configuration in
925	   use, it can join the secure AODV-RPL route discovery and cause
926	   various types of damage.  Such a rogue router could advertise false
927	   information in its DIOs in order to include itself in the discovered
928	   route(s).  It could generate bogus RREQ-DIO, and RREP-DIO messages
929	   carrying bad routes or maliciously modify genuine RREP-DIO messages
930	   it receives.  A rogue router acting as the OrigNode could launch
931	   denial-of-service attacks against the LLN deployment by initiating
932	   fake AODV-RPL route discoveries.  In this type of scenario, RPL's
933	   authenticated mode of operation, where a node can obtain the key to
934	   use for a P2P-RPL route discovery only after proper authentication,
935	   SHOULD be used.

[major] rfc6550 says this:

   Authenticated mode cannot be supported by symmetric algorithms. As of the
   writing of this specification, RPL supports only symmetric algorithms:
   authenticated mode is included for the benefit of potential future
   cryptographic primitives.

If I'm interpreting this correctly, there is really no authentication
defined for RPL that can apply here.  Has something been defined after
that?  IOW, what "SHOULD be used"?


937	   When RREQ-DIO message uses source routing option with 'H' set to 0,
938	   some of the security concerns that led to the deprecation of Type 0
939	   routing headers [RFC5095] may apply.  To avoid the possibility of a
940	   RREP-DIO message traveling in a routing loop, if one of its addresses
941	   are present as part of the Source Route listed inside the message,
942	   the Intermediate Router MUST NOT forward the message.

[major] rfc5095 will probably raise a lot of flags...

Suggestion>
   When a RREQ-DIO message uses the source routing option by setting the H
   bit to 0, a rogue router may populate the Address Vector field with a set
   of addresses that may result in the RREP-DIO traveling in a routing loop.
   The TargNode MUST NOT generate a RREP if one of its addresses is present
   in the Address Vector.  An Intermediate Router MUST NOT forward a RREP if
   one of its addresses is present in the Address Vector.



944	11.  Link State Determination

[major] There's already text in §5 that pretty much says the same
thing...except for the first sentence; I couldn't find a place where
it says that symmetric is the default, did I miss it?

In any case, I think that because of the text in §5, this section is not needed.

946	   This document specifies that links are considered symmetric until
947	   additional information is collected.  Other link metric information
948	   can be acquired before AODV-RPL operation, by executing evaluation
949	   procedures; for instance test traffic can be generated between nodes
950	   of the deployed network.  During AODV-RPL operation, OAM techniques
951	   for evaluating link state (see([RFC7548], [RFC7276], [co-ioam]) MAY
952	   be used (at regular intervals appropriate for the LLN).  The
953	   evaluation procedures are out of scope for AODV-RPL.


955	12.  References

957	12.1.  Normative References
...
964	   [RFC3561]  Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
965	              Demand Distance Vector (AODV) Routing", RFC 3561,
966	              DOI 10.17487/RFC3561, July 2003,
967	              <https://www.rfc-editor.org/info/rfc3561>.

[major] This doesn't have to be a Normative reference.


...
991	   [RFC6998]  Goyal, M., Ed., Baccelli, E., Brandt, A., and J. Martocci,
992	              "A Mechanism to Measure the Routing Metrics along a Point-
993	              to-Point Route in a Low-Power and Lossy Network",
994	              RFC 6998, DOI 10.17487/RFC6998, August 2013,
995	              <https://www.rfc-editor.org/info/rfc6998>.

[major] This shouldn't be a Normative reference.

Please make both of them Informative to avoid the DownRef.