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

[Alvaro Retana <[e-mail]>]

Ping!

On June 16, 2020 at 5:36:50 PM, Alvaro Retana ([e-mail])
wrote:


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.