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

From: Alvaro Retana <[email-masked]>
Date: Fri, 6 Nov 2020 17:10:18 -0500

On October 28, 2020 at 5:29:25 PM, Pascal Thubert wrote:

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

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

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

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.

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.

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

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

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'm wondering if there again the end of your message was lost?

Nope, that was it. :-)

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 9 Nov 2020 08:58:26 +0000

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
> > > Does this mean that §12.5 should also be changed to include the
> > > DCO-ACK message in it?
> >

Oh I see, done.

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

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.

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

---

From: Alvaro Retana <[email-masked]>
Date: Mon, 9 Nov 2020 11:13:55 -0800

On November 9, 2020 at 3:58:44 AM, Pascal Thubert wrote:

Pascal:

Hi!

I'm ok with the document as is...just one comment remaining.  You can
take it as a Last Call comment.

I'll start the IETF LC when I get updated versions of both this and
UseofRPLInfo.  If you're ready to submit before the window opens
again, feel free to ask the Secretariat ([email-masked])
for manual posting -- I'll approve.

Thanks!

Alvaro.

...
> > > Nothing prevents a packet coming in a RPL domain to carry an RPI.
.
> 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.

As I was reading UseofRPLInfo-41...  §6 (Use Cases) now says this (one
of the assumptions in the use cases):  "For traffic leaving a RUL, if
the RUL adds an opaque RPI then the description of the RAL applies."

This is what I was looking for (in UseofRPLInfo) in terms of how to
handle an RPI from the RUL.  There is however a difference between
what is now written in unaware-leaves and what UseofRPLInfo says (in
the "RAL to..." cases).  In general, UseofRPLInfo says that the 6LR
modifies the RPI, but provide no details except for mentioning the
rank...  The difference is that unaware-leaves says that if the sender
was a RUL then the 6LR "SHOULD rewrite the RPI".

I think that we could simply add the Normative text from above to the
sentence in §6/UseofRPLInfo to bring them all in sync:

NEW>
   - For traffic leaving a RUL, if the RUL adds an opaque RPI then the
     description of the RAL applies.  The 6LR as a RPL border router SHOULD
     rewrite the RPI to indicate the selected Instance and set the flags.