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

[Charlie Perkins <[e-mail]>]

Hello Alvaro and all,

Here are some follow-up comments for your review review of our document.

On 6/16/2020 2:36 PM, Alvaro Retana wrote:
> ....
>
> [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


Check.


> [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?

If the route is the same, it will have the same metric.  If the metrics 
are different for two routes discovered at about the same time, then the 
route with the more favorable metric should be chosen.  When two 
different routing protocols are in operation, route timeout parameters 
should be chosen according to the needs of the networks operating the 
protocols.  For this reason, the decision about which of two routes to 
prefer seems to be outside of the scope of AODV-RPL.  Since AODV-RPL can 
discover any route that is discoverable by RPL, it isn’t necessary to 
run both protocols at the same time; nevertheless, it is possible to do 
so and not prohibited.

Before establishing a P2P route, the OrigNode checks whether there is 
already a route to TargNode which meets the OF of the application. If 
there is one, OrigNode does not have to initiate AODV-RPL route 
discovery. Even if native RPL has established a symmetric route symmetry 
between OrigNode and TargNode, AODV-RPL can still be invoked to discover 
an asymmetric route between OrigNode and TargNode which meets the 
application OF at reduced cost.

>
> [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.

Since the route table entries for AODV-RPL are upwards compatible with 
RPL, needing only the addition of the sequence numbers, I think it makes 
sense to initially populate the AODV-RPL route table information by 
importing the existing RPL information.


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

Check.

> 298 4.1. AODV-RPL DIO RREQ Option
>
> 300 OrigNode sets its IPv6 address in the DODAGID field of the RREQ-DIO
> 301 message. A RREQ-DIO message MUST carry exactly one RREQ option.
>
> [major] What should a receiver do if more than one RREQ options are
> received?


I specified that it SHOULD be dropped. I don't think this is too harsh,
even though other solutions are possible.

> [major] When would the receiver not drop the RREQ-DIO?  IOW, why
> wouldn't it always drop it (MUST)?  If it is not
> dropped...then...should all the options be processed?
>
> These questions go back to the reason only one RREQ option is
> expected.  From §6.1, it seems like one is enough...specially given
> that multiple ART options can be present.
>
> Are there cases where more than one RREQ option could be "normal"?


Yes, it is enough for there to be just one RREQ option in a DIO.   I 
could imagine a beneficial use for multiple RREQ options, but I can’t 
imagine going through the exercise of specifying an interoperable 
behavior right now.  That was my reasoning for the SHOULD drop.  But I 
am O.K. with MUST drop, and if a future specification changes the 
behavior, then this prohibition can be updated in that future specification.

> ...
> 363 L is independent from the route lifetime, which is defined in the
> 364 DODAG configuration option. The route entries in hop-by-hop
> 365 routing and states of source routing can still be maintained even
> 366 after the DAG expires.
>
> [??] I don't understand what the last sentence is trying to say. It
> sounds as if the information learned through the DAG can still be used
> after the DAG expires...up until the route lifetime expires...is that it?
> Please clarify.
>
> How about this:
>
>
> The route entries in hop-by-hop routing
> and states of source routing can still be maintained
> even after the node no longer maintains DAG connectivity or
> messaging.
>
> Why would the node want to maintain the information after it is 
> disconnected?
>
> Put another way, I understand why L is independent of the route
> lifetime.  I don't understand why the information would be kept. The
> text says that it "can still be maintained", not that it has to be
> maintained -- is there a value in keeping it?
>
> Maybe simply remove the last sentence...??
>


The reason for keeping the route information would be so that the 
destination sequence number information could be maintained, much as it 
is in AODV.  We could, instead, suggest that the information MAY be 
contained in an auxiliary data structure maintained external to the 
route table.  The information could be helpful to help dispose of random 
RREQs that might for some unknown reason still be circulating from 
previous route discovery operations.  However, as far as I know, no one 
has reported such a phenomenon in the intended networks where AODV-RPL 
would be deployed.

So, in the interest of progressing the document, I suggest simply 
deleting the last sentence.


> 389 4.2. AODV-RPL DIO RREP Option
>
> 391 TargNode sets its IPv6 address in the DODAGID field of the RREP-DIO
> 392 message. A RREP-DIO message MUST carry exactly one RREP option.
> 393 TargNode supplies the following information in the RREP option:
>
> [major] What should the receiver do if more than one RREP option is
> received?
>
> How about:
>
> A RREP-DIO message MUST carry exactly one RREP option,
> otherwise the message SHOULD be dropped.
>
> [major] When would the receiver not drop the RREQ-DIO?  IOW, why
> wouldn't it always drop it (MUST)?  If it is not
> dropped...then...should all the options be processed?
>
> These questions go back to the reason only one RREP option is
> expected.  From §6.3, it seems like one is all that is needed.
>
> Are there cases where more than one RREP option could be "normal"?

O.K., we can require dropping the packet if more than one RREP option is 
present.

     ....   .  A RREP-DIO message MUST carry exactly one RREP option,
     otherwise the message MUST be dropped.

> ...
> 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.

Check.


> ...
> 441 Shift
> 442 6-bit unsigned integer. This field is used to recover the
> 443 original InstanceID (see Section 6.3.3); 0 indicates that the
> 444 original InstanceID is used.
>
> [major] s/InstanceID/RPLInstanceID/g


Done.

> 446 Rsv
> 447 MUST be initialized to zero and ignored upon reception.
>
> [major] Do you expect these bits to be assigned by IANA in the future?

No, but a future specification could modify the operation. Do we need to 
say that?

> ...
> 456 4.3. AODV-RPL DIO Target Option
> ...
> 464 A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO
> 465 message MUST carry exactly one ART Option.
>
> [major] What should a node do if more than one ART Option is received in
> a RREP-DIO message?
>
> How about:
>
> A RREQ-DIO message MUST carry at least one ART Option. A RREP-DIO
> message MUST carry exactly one ART Option. Otherwise, the message
> SHOULD be dropped.
>
>
> [major] When would the receiver not drop the RREP-DIO?  IOW, why
> wouldn't it always drop it (MUST)?  If it is not
> dropped...then...should all the options be processed?  From §6.3, it
> seems like one is all that is needed.
>
> Are there cases where more than one ART option could be "normal"? The
> RREQ can include multiple, but the RREP only one -- I didn't find a
> place where it was clear that processing these ART options should
> result in one reply, but I may have missed it.

I changed it:
     A RREQ-DIO message MUST carry at least one ART Option.  A RREP-DIO
     message MUST carry exactly one ART Option. Otherwise, the message
     MUST be dropped.

> ...
> 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.

Done.

> ...
> 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.

Fixed.


> 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.

Done.

> ...
> 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

Done - thanks!


> 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).

Done.

> ...
> 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.

How about:
         If the S bit of the RREP-DIO is set to 0, the router MUST determine
         whether the downward direction of the link (towards the TargNode)
         over which the RREP-DIO is received satisfies the Objective
         Function, and the router's Rank would not exceed the MaxRank
         limit.  If so, the router joins the DODAG of the RREP-Instance.


> ...
> 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.

Agreed.  Done.


> 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.

Done.



> ...
> 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.

There is the harm of propagating useless traffic.

> ...
> 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.


Done and done.


> 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.


Done and done.


> 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!


oopsies


>> 920 10. Security Considerations
>>
>> 922 The security mechanisms defined in section 10 of [RFC6550] and
>> 923 section 11 of [RFC6997] can also be applied to the control messages
>> 924 defined in this specification. The RREQ-DIO and RREP-DIO both have a
>> 925 secure variant, which provide integrity and replay protection as well
>> 926 as optional confidentiality and delay protection.
>> ...
>> [minor] §3 talks about the fact that an RREQ-DIO is a DIO message
>> with the rREQ Option (and there's similar text for the RREP-DIO).
>> However, I think it's confusing to the reader to mention that there are
>> secure variants. I think that expanding the description (at the end of
>> §3) of what exactly the *-DIO messages are (and that the definition
>> includes the secure variants) would go a long way.
>
>
> Is it O.K. if we note that RREQ and RREP have secure variants, without
> having to reproduce the entire section?
>
> I think so — pointing to rfc6550.

Done.

> 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.

I know what you meant :-)

> ...
> 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"?


How about:

                                         In this type of scenario, RPL's
       preinstalled mode of operation, where the key to use for a P2P-RPL
       route discovery is preinstalled, SHOULD be used.  If a future
       IETF document specifies the authenticated mode of operation as
       described in RFC 6550, then future AODV-RPL implementations SHOULD
       use the authenticated mode of operation.


> 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.

Thanks, done.


> 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.

Deleted - thanks!


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.

I moved it.


> ...
> 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.

Done, and thanks!

-----------------------------------------------------------------------------------------------------

Many thanks for the review, and wishing you a very merry holiday season.

Regards,
Charlie P.