Re: [Roll] AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont)

["Pascal Thubert (pthubert)" <[e-mail]>]

Many thanks Alvaro!

I committed to git but the IETF datatracker is locked till next week.
Please find the delta here:

https://github.com/roll-wg/roll-unaware-leaves/commit/6068e40d6450b33e664460d606e860401cc9a5c3

more below : )

> 
> Hi Pascal!
> 
> 
> There are just a couple of remaining comments...nothing major.  I will start
> the IETF LC when you upload an update. :-)
> 
> Thanks!!
> 
> Alvaro.
> 
> 
> 
> ...
> > > > But we're also merging the statis with the DCO-ACK Status In that
> > > > we deprecate
> > > > https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-dco-ack-status
> > >
> > > That is new!! I don't even see DCO-ACK mentioned in the document at all.
> > >
> > > Does this mean that §12.5 should also be changed to include the
> > > DCO-ACK message in it?
> >
> > Not sure I understand. §12.5 Has the only DCO status, status 1.
> 
> §12.5 says this:
> 
>    This specification creates a new Subregistry for the RPL Non-
>    Rejection Status values for use in the RPL DAO-ACK and DCO messages
>    with the 'A' flag reset, under the RPL registry.
> 
> s/DAO-ACK and DCO/DAO-ACK, DCO, and DCO-ACK
> 
> 

Oh I see, done.

> 
> ...
> > > [major] What should the receiver do if a different value is used?
> > >
> > Added
> > "
> > ROVRsz (ROVR Size): Indicates the Size of the ROVR. It SHOULD be 1, 2,
> > 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits,
> > respectively. If a legacy Target Option is used, then the value must
> > remain 0, as specified in [RFC6550]; In case of a value above 4, the
> > size of the ROVR is undetermined and this node cannot validate the
> > ROVR; an implementation SHOULD propagate the whole Target Option
> > upwards as received to enable the verification by an ancestor that
> > would support the upgraded ROVR.
> > "
> 
> [nit] s/[RFC6550]; In/[RFC6550]. In

Done

> 
> 
> [major] "value above 4, the size of the ROVR is undetermined and this node
> cannot validate the ROVR; an implementation SHOULD propagate the whole
> Target Option upwards as received to enable the verification by an ancestor
> that would support the upgraded ROVR."
> 
> Several points:
> 
> 1- Maybe I missed it, but I didn't see anywhere that a RPL node would validate
> the ROVR.  Is that implicit somehow?  Note that I'm referring to RPL
> functionality since we're talking about the Target Option (not from rfc8505's
> point of view).
 
As of now, the only verification is by the 6LBR, when the Root proxies the EDAR. It is important that the intermediate routers transport the ROVR even if they do not understand it, so the Root can do appropriate proxying. The 6LBR verifies that the ROVR is the same, else it triggers a validation by the 6LR.

This may happen in the case where the 6LN does not claim the ROVR is cryptographic and thus the 6LR does not do the validation, but the ROVR already existed at the 6LBR and was seen as cryptographic, so the 6LBR triggers the check.

See https://www.rfc-editor.org/authors/rfc8928.html
"
The 6LR MUST indicate to the 6LBR that it performed a successful validation by setting a status code of 5 ("Validation Requested") in the EDAR. Upon a subsequent EDAR from a new 6LR with a status code that is not 5 for a validated Binding, the 6LBR MUST indicate to the new 6LR that it needs to challenge the 6LN using a status code of 5 in the EDAC.
"

Now, it is my hope that in the future we add an ROV (route ownership validation) method to RPL, based on the ROVR.

> 2- It seems to me that both the 6LR and then the Root simply copy the ROVR
> from/to the EDAR.  IOW, there doesn't seem to be another RPL ancestor who
> would do anything with it.
 
True, this spec does not have a backward compatibility issue. 
But we are still changing the DAO for all modes. So I thought we need to indicate what the behavior is in other modes as well.


> 3- Assuming that the 6LR somehow originated a bad Target Option (with a
> ROVRsz > 4), then it looks like the Root wouldn't be able to send an
> EDAR.  What should it do?  I'm guessing it should send a failure signal back to
> the 6LR.

True. I guess that could be a bad RPL status on the DAO-ACK; if there is no ACK requested it could be a DCO. 
I'm wondering if we should start defining RPL statuses. Note that the case is either a bug or a backlevel Root, IOW a deployment issue. 
We should not complexify the code overtly for any if those case.

> 
> 4- We're making assumptions about an "upgraded ROVR".
> 
> 
> To solve all this maybe just delete starting with "In case of a value above
> 4..."   If RPL is just carrying the information then that seems more an rfc8505
> issue...
> 

Well, the 6LR is capable of placing a larger ROVR and the Root does not understand it. This needs to be reported to the network admin. 
I'm not too happy removing the sentence for the reasons above. I'll do this git commit with it but keep the point open.


> > Nothing prevents a packet coming in a RPL domain to carry an RPI.
> > E.g., that packet escaped another RPL domain, which is now valid. The
> > border router (typically the root) must rewrite it. the question is
> > whether we assume that the RUL placed a meaningful one. I'd say that
> > cannot be assumed in all cases, e.g., if instead of a leaf we have
> > another RPKL network.
> > But when it is useful, the 6LR should have a policy to know so it
> > knows how to use it.
> ...
> > I added
> > "
> > If the packet from the RUL has an RPI, the 6LR as a RPL border router
> > MUST rewrite the RPI to indicate the selected Instance and set the
> > flags, but it does not need to encapsulate the packet.
> > "
> >
> > Also added
> >
> > "
> > It is up to the 6LR (e.g., by policy) to use the RPLInstanceID
> > information provided by the RUL or rewrite it to the selected
> > RPLInstanceID for forwarding inside the RPL domain.
> > "
> 
> Good...except that I think there's a Normative conflict: "the 6LR...MUST
> rewrite the RPI" vs "up to the 6LR...to use...or rewrite".
>  s/MUST/SHOULD

Done, though unconvinced. "up to the 6LR..." has no normative text on the 6LR behavior, just on the 6LN. 

> 
> Should any of this be also in UseofRPLInfo?  Or maybe it should be explained
> there and referenced form here.  UseofRPLInfo talks about always inserting
> the RPI at the 6LR, no exceptions.
> 

I'll open a thread; your point on the security section could be reflected there, that if the external destination passes a packet with a RPI then the RPI should be revisited or encapsulated.


> 
> 
> ...
> > I'm wondering if there again the end of your message was lost?
> 

Great, ready to publish when you (and the datatracker) are!

Take care,

Pascal