Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-aodv-rpl-11: (with DISCUSS and COMMENT)

[Charles Perkins <[e-mail]>]

Hello Benjamin,

Thank you for your detailed review.  It is very much appreciated, and is 
helping us to make some significant improvements in the document.  
Please see our follow-up and proposed resolutions below.



On 10/29/2021 4:01 PM, Benjamin Kaduk via Datatracker wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-roll-aodv-rpl-11: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer tohttps://www.ietf.org/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thanks for the updates in the -11, they are a bit improvement.
>
> (1) I did make a point of looking into the procedures for determining
> whether a route will be symmetric or asymmetric, and I'm running into
> trouble for the case where an intermediate router determines that a link
> cannot work as part of a symmetric route.
>
> For concreteness, let's consider the following snippet of topology:
>
>    +-------+                   +-------+                   +-------+
>    |       |    asymmetric     |       |                   |       |
>    |   A   +-------------------+   B   +===================+   C   |
>    |       |       L1          |       |       L2          |       |
>    +-------+                   +-------+                   +-------+
>
> Suppose that an RREQ-DIO arrives at A with S=1 and H=0.  Per step 3 of
> §6.2.1, if the link the RREQ-DIO arrived on satisfies the objective
> function, the outgoing RREQ-DIO is also transmitted with S=1.
> A also associates state with its RREQ-Instance the value of the S bit
> from the transmitted RREQ-DIO, i.e., 1.
Check.
> That RREQ-DIO arrives at B, who performs the same check and determines
> that the L1 cannot satisfy the objective function.  Accordingly, B sends
> out a RREQ-DIO to C with S=0 and stores the state S=0.

If the route to OrigNode from B via L1 cannot satisfy the objective 
function, B drops the RREQ-DIO.  Otherwise, if L1 is asymmetric but 
still provides a usable path towards OrigNode, B takes the action you 
describe.

>    The RREQ-DIO
> continues to through C to TargNode (or maybe C is TargNode; it may not
> matter), and TargNode proceeds to follow asymmetric procedures,
> initiating an RREP-DIO with an initially empty address vector.  That
> RREP-DIO arrives at C, who has stored state S=0, so C joins the DODAG of
> the RREP-Instance, adds its address to the address vector (per step 4 of
> §6.4), and sends an RREP-DIO to B.  B likewise has stored state S=0,
> adds its address to the address vector, and sends an RREP-DIO to A.  But
> A has stored state S=1, so in step 4 of §6.4, A is looking for an
> address in the address vector to use as the unicast target for A's
> outgoing RREP-DIO.  But there is no such entry in the address vector,
> becuase up to now the RREP-DIO has been using asymmetric procedures, and
> has no data on how to get from A to OrigNode!

As the RREQ-DIO propagates with H=0, every node that transmits the 
RREQ-DIO can be used in a source route to OrigNode.  So, when the RREQ 
is received by B, B has an address vector utilizing A as the next hop 
for a route to OrigNode.

If the RREQ-Instance at B has S=1, B should optionally be allowed to 
associate that address vector with the RREQ-Instance.  For S=1, the 
address vector B-->...->OrigNode is symmetric; if B maintains that 
information, it could unicast an incoming RREP towards OrigNode.

We will add an appendix with some examples to make this more clear.

>
> Now, it's certainly possible that I've made an error in the above.  But
> even if I have, it still seems suggestive that this boundary behavior is
> pretty complicated and hard to get right.  It seems like we should have
> some similar discussion in the document to cover how this case does
> actually work.
>
> (And if I didn't make an error in the above, it seems to still be
> salvageable, with B storing a sentinel value of "I changed from S=1 to
> S=0" instead of just 1 or 0, and holding on to the (symmetric) address
> vector from OrigNode to B.  Then B could perform translation from the
> asymmetric to symmetric regime for the RREP and all routers on the path
> would be able to install useful route entries.  But there's not anything
> in the current text to suggest that B should be doing that.)

As described above, I agree about the usefulness of allowing an 
intermediate node to store a symmetric address vector.  This will be 
specified as an optional behavior in the revised document.

>
> (2) I'm putting this in the Discuss section because I think it's
> important for the authors/WG to produce an answer.  Since I've been
> wrong about it at least once, I do not claim to know the correct answer,
> and thus the Discuss point ought to be easy to resolve.
>
> Section 6.3.3 says:
>
>                            Instead, the RPLInstanceID MUST be replaced by
>     another value so that the two RREP-instances can be distinguished.
>     In RREP-DIO option, the Shift field of the RREP-DIO message(Figure 2)
>     indicates the shift to be applied to original RPLInstanceID to obtain
>     the replacement RPLInstanceID.  When the new RPLInstanceID after
>     shifting exceeds 255, it rolls over starting at 0.  For example, if
>     the original RPLInstanceID is 252, and shifted by 6, the new
>     RPLInstanceID will be 2. [...]
>
> I know that the use of 255 as the largest value here comes as a result
> of my earlier review, but wanted to note that the resulting discussion
> thread may not have fully concluded.
> In particular, I now see
> https://datatracker.ietf.org/doc/html/rfc6550#section-5.1  that does
> indicate that only 6 bits of "usable" ID are present for local
> RPLInstanceIDs, which seem to be the ones in use here.  Sorry to have
> missed that in my initial review; I hope that we can figure out what the
> actual correct boundary value is.

All 8 bits of the ID are usable.  The design allows for 64 possible 
alternative choices in the case of a collision.  Collisions are rare, so 
that should be plenty.  Providing a "shift" operation does not place any 
restriction on use of all 8 bits for choice of ID.  It just enables the 
elimination of ID collisions for all foreseeable cases.


>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Some of the text I comment on below is new in the -11, and I would have
> hoped that WG review of the changes would have detected more of this
> type of thing.  This leaves me uncertain what level of review the WG
> actually performed, and I am considering balloting Abstain once my
> discuss points are resolved.
>
> Section 3
>
>     to TargNode, and another from TargNode to OrigNode.  When possible,
>     AODV-RPL also enables symmetric route discovery along Paired DODAGs
>     (see Section 5).
>
> (Modifying a comment I made on the -10) Perhaps we could say "AODV-RPL
> also enables discvoery of symmetric routes along Paired DODAGs when
> symmetric routes are possible (see Section 5)"?

We can use the suggested wording.
>
> Section 4.2
>
>     L
>        2-bit unsigned integer defined as in RREQ option.
>
> Per the discussion on my previous ballot thread, I suggest adding "The
> lifetime of the RREP-Instance MUST be shorter than the lifetime of the
> RREQ-Instance it is paired to" (or similar).

We can use the suggested wording.
>
> Section 4.3
>
>     Target Prefix / Address
>        (variable-length field) An IPv6 destination address or prefix.
>        The Prefix Length field contains the number of valid leading bits
>        in the prefix.  The Target Prefix / Address field contains the
>        least number of octets that can represent all of the bits of the
>        Prefix, in other words Ceil(Prefix Length/8) octets.  The initial
>        bits in the Target Prefix / Address field preceding the prefix
>        length (if any) MUST be set to zero on transmission and MUST be
>        ignored on receipt.  If Prefix Length is zero, the Address field
>        is 128 bits for IPv6 addresses.
>
> This is a change from the -10 about where the target prefix is aligned
> for prefix lengths that are not a multiple of 8.
> I have no stance on which formulation is best, but it seems very
> surprising to change the wire encoding in this manner at such a late
> stage in the document lifecycle, without specific compelling reasoning.

It is still allowable to have Prefixes that are not multiples of 8. It's 
just that representing those prefixes still takes an integral number of 
bytes in the message field.  For prefixes that are not multiples of 8, 
some of the bits in the message field are ignored.
>
> Section 6.2.1
>
>     Step 1:
>
>        The router MUST first determine whether to propagate the RREQ-DIO.
>        It does this by determining whether or not the downstream
>        direction of the incoming link satisfies the Objective Function
>        (OF).  If not the RREQ-DIO MUST be dropped, and the following
>        steps are not processed.  Otherwise, the router MUST join the
>        RREQ-Instance and prepare to propagate the RREQ-DIO.  The upstream
>        neighbor router that transmitted the received RREQ-DIO is selected
>        as the preferred parent.
In the second sentence above, s/downstream/upstream/ .  By propagating 
the RREQ-DIO, a router indicates that it has a route to OrigNode.  
Please excuse this confusing typo.

>     [...]
>     Step 3:
>
>        If the S bit of the incoming RREQ-DIO is 0, then the route cannot
>        be symmetric, and the S bit of the RREQ-DIO to be transmitted is
>        set to 0.  Otherwise, the router MUST determine whether the
>        downward (i.e., towards the TargNode) direction of the incoming
>        link satisfies the OF.  If so, the S bit of the RREQ-DIO to be
>        transmitted is set to 1.  Otherwise the S bit of the RREQ-DIO to
>        be transmitted is set to 0.
>
> The step 1 procedure checks the downstream direction of the incoming
> link, and the step 3 procedure also checks the dosntream direction of
> the incoming link.  In order to assess whether the link works as a
> symmetric link, I think that these checks need to be on different
> directions of that link, but am not confident about which step should
> check which direction.

As indicated above, Step 1 verifies the upstream direction.   Here is a 
restatement of the processing that is specified for handling the 
RREQ-DIO.  The revised document will reorganize the procedure to 
emphasize these points.

  * A RREQ-DIO arrives at intermediate node J from neighbor N across the
    incoming link.

  * If the incoming link J->N causes the OF to be unsatisfiable for a
    route to OrigNode, drop and do not continue these steps.

  * Otherwise the path J->OrigNode satisfies the OF.  In other words, J
    verifies that neighbor N is a usable next hop for a route to
    OrigNode.  In this case, node J prepares to advertise the
    availability of a route to OrigNode, by propagating the RREQ-DIO.

  * If 'S' bit is NOT set, there is nothing more to do.  Transmit the
    RREQ-DIO.

  * If, on the other hand, the 'S' bit is set, check whether or not the
    downstream direction of the incoming link still allows a usable path
    for OrigNode to send packets to TargNode.     Since the 'S' bit was
    set, the OF for the path Orig-->N is advertised to be (roughly) the
    same as the OF for the path N-->Orig.  From the above, the OF is
    satisfied for the path J --> Orig.  If J sets the 'S' bit in the
    outgoing RREQ-DIO, that means that the OF for the path J-->Orig is
    the same as the OF for the path Orig-->J.  Because the incoming
    RREQ-DIO had the 'S' bit set, this can be done by ascertaining that
    the OF for J-->N is the same as the OF for the N-->J.


>
> section 6.3
>
>                                                                If the
>     implementation selects the symmetric route, and the L field is not 0,
>     the TargNode MAY delay transmitting the RREP-DIO for duration
>     RREP_WAIT_TIME to await a route with a lower Rank.  The value of
>
> In the -10 the text allowing waiting was present in both the section for
> the symmetric case and the section for the asymmetric case; is the
> conditional "if the implementation selects the symmetric route" correct?

We intend to allow waiting for both symmetric and asymmetric cases.
>
> Section 6.3.2
>
>     When a RREQ-DIO arrives at a TargNode with the S bit set to 0, the
>     TargNode MUST build a DODAG in the RREP-Instance corresponding to the
>     RREQ-DIO, rooted at itself in order to discover the downstream route
>
> nit: this comma is misplaced (and may not be needed at all).

"RREQ-DIO, rooted at itself"   -->  "RREQ-DIO rooted at itself,"

>
> Section 6.4
>
>     Upon receiving a RREP-DIO, a router performs the following steps:
>
>     Step 1:
>
>        If the Objective Function is not satisfied, the router MUST NOT
>        join the DODAG; the router MUST discard the RREQ-DIO, and does not
>
> s/RREQ/RREP/?

Yes, indeed, you are correct.

>
>        If the S-bit of the RREQ-Instance 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.  The router that transmitted the received RREP-DIO is
>        selected as the preferred parent.  Afterwards, other RREP-DIO
>        messages can be received.
>
> Please confirm whether "downward direction" is correct.

If intermediate node 'J' propagated a RREQ-DIO, J has a route to OrigNode.

If the intermediate node 'J' retransmits the RREP-DIO, it is advertising 
a route to TargNode.  If the S-bit of the RREQ-Instance is zero, the 
RREP-DIO (i.e., route advertisement) is multicast.  If 'S'=1, and H=1, J 
unicasts the RREP-DIO is unicast to the next hop of the route that J has 
available towards OrigNode.  For H=1, this route is available from the 
stored route that J has for OrigNode (if H=1).  If H=0, the behavior 
depends on whether or not J has stored the address vector to OrigNode 
which was included with the RREQ-DIO.  In that case, J MAY append the 
Address Vector to the address vector in the RREP-DIO, providing a 
complete address vector OrigNode --> TargNode.  In this case J SHOULD 
unicast the RREP to the next hop along the way to OrigNode.

In other words, "downward direction" is correct.  The clause preceding 
it can be omitted.

An interesting case occurs when an RREP arrives at an intermediate node 
J that has not received the corresponding RREQ.  In this case, assuming 
that the OF is satisfied towards TargNode, J multicasts the RREP and the 
protocol proceeds exactly as before, except that the RREP-instance is 
not paired with a RREQ-instance.  If the RREP-DIO propagated by J 
arrives at OrigNode, then OrigNode will have a route to TargNode.  
OrigNode will also be able to associate the RREP-DIO with the RREQ-DIO 
which initiated the route discovery.  We will make this refinement for 
the notion of paired instances.


>    It seems to me
> that in determining whether to join the RREP-Instance, we need to check
> whether the "reply path" (from TargNode to OrigNode) is feasible, and
> skip joining the instance if it's not a feasible path.  But the text
> written here seem to be checking the feasibility of the "request path",
> the same direction that was checked in §6.2.1 when deciding whether to
> join the RREQ-Instance.

 From the above, if B joins the RREP-Instance and propagates the RREP 
with H=1, it is advertising a route to TargNode.  Analogously, for H=0, 
B is providing an address vector B --> TargNode which upstream nodes can 
extend.  When the RREP arrives at OrigNode, the RREP has an address 
vector usable by OrigNode to transmit data to TargNode.

>
> Section 10
>
> Thanks for acting on my previous comment and moving the normative
> requirements on nodes to not emit RREPs if they have an address in the
> address vector already!  I still think it would be worth some text here
> in the security considerations about what goes wrong if those checks are
> skipped (I think, a routing loop occurs, but that's something of a
> guess).

I also think a routing loop is the main concern here.
>
> It seems that if Compr is set too large, there is some risk of a node
> failing to check that it shares that many bits of address prefix with
> the address in the DODAGID and thus decompression would produce an
> incorrect route.

We could provide additional specification, but I am not sure it is needed.

Old:

    Compr
       4-bit unsigned integer.  Number of prefix octets that are elided
       from the Address Vector.  The octets elided are shared with the
       IPv6 address in the DODAGID.  This field is only used in source
       routing mode (H=0).  In hop-by-hop mode (H=1), this field MUST be
       set to zero and ignored upon reception.

New:

    Compr
       4-bit unsigned integer.    When Compr is nonzero, exactly that
       number of prefix octets MUST be elided from each address in
       the Address Vector.  The octets elided are shared with the
       IPv6 address in the DODAGID.  This field is only used in source
       routing mode (H=0).  In hop-by-hop mode (H=1), this field MUST be
       set to zero and ignored upon reception.

Does this resolve the problem?

>
>     If a rogue router is able to forge a gratuitous RREP, significant
>     damage might result.
>
> Would this damage be in the form of traffic amplification, routing loop,
> DoS of certain (key) nodes, ...?
>
>
I think the main danger is from disrupting the route discovery, and so 
DoS.  Or, if the rogue router knows more about the topology, it could 
maliciously direct traffic to an unwilling recipient, providing another 
kind of DoS.

Regards,
Charlie P.