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

Benjamin Kaduk <kaduk@mit.edu> Mon, 21 March 2022 20:40 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBD3B3A1AF4; Mon, 21 Mar 2022 13:40:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.721
X-Spam-Level:
X-Spam-Status: No, score=-1.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.186, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RN2TI_7AMa78; Mon, 21 Mar 2022 13:40:49 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6F43A1B09; Mon, 21 Mar 2022 13:40:48 -0700 (PDT)
Received: from mit.edu (c-73-169-244-254.hsd1.wa.comcast.net [73.169.244.254]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 22LKecIJ006021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 21 Mar 2022 16:40:44 -0400
Date: Mon, 21 Mar 2022 13:40:37 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Charles Perkins <charliep@lupinlodge.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles <mariainesrobles@googlemail.com>, aretana.ietf@gmail.com
Message-ID: <20220321204037.GX13021@mit.edu>
References: <163554851494.11244.14085107396965188459@ietfa.amsl.com> <e0f11565-98e3-1722-2ef3-06fd903c2028@lupinlodge.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <e0f11565-98e3-1722-2ef3-06fd903c2028@lupinlodge.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/oGT9zoWRSV68BWyxPh-pNTo-L2w>
Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-aodv-rpl-11: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Mar 2022 20:40:52 -0000

Hi Charlie,

Thanks for the response, and my apologies for having delayed so long in
responding.

On Thu, Dec 23, 2021 at 08:54:04AM -0800, Charles Perkins wrote:
> 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:
> >
> >
> > 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.

Okay, this all makes sense.  I'm rather curious what happens if B does not
maintain that information -- would we have to rely on some other path
existing and just accept non-reachability otherwise?

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

(This seems to still be pending, though I wasn't going to insist on
examples in the first place.)

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

Okay, thank you for double-checking.

> 
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------

Trimming...

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

Sorry, I was unclear here.  In my reading what changed was whether the
padding bits were "on the left" or "on the right" (when there are padding
bits at all).  That is, in the -10, I thought that even for
non-multiple-of-8 prefix length, the non-padding bits were aligned to start
at the beginning (left) of the field, whereas in the -11 and later these
initial bits are the padding bits.

[LOTS of very informative detailed explanations trimmed -- thank you!]

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

That seems like an okay change to make, but I was mostly asking about
putting a sentence in the security considerations to the effect of "use of
address/prefix compression can introduce errors in the recovered
address/prefix, if the router applying compression does not properly check
that the bits being elided are compressible".

Thanks,

Ben