Subject: Re: [Roll] Erik Kline's Discuss on draft-ietf-roll-useofrplinfo-42: (with DISCUSS and COMMENT)

From: Alvaro Retana <[email-masked]>
Date: Tue, 5 Jan 2021 12:25:33 -0800

Hi!

Where are we with this?   It is not clear whether we need to update the
document or if we’re all agreeing. ;-)

Erik/Pascal?

Thanks!

Alvaro.

On December 18, 2020 at 10:42:24 AM, Pascal Thubert (pthubert) (
pthubert=[email-masked]) wrote:

Hello Michael and all:

> -----Original Message-----
> From: Roll <[email-masked]> On Behalf Of Michael Richardson
> Sent: mercredi 16 décembre 2020 19:02
> To: Erik Kline <[email-masked]>; Routing Over Low power and Lossy
> networks <[email-masked]>
> Subject: Re: [Roll] Erik Kline's Discuss on
draft-ietf-roll-useofrplinfo-42: (with
> DISCUSS and COMMENT)
>
>
> Erik Kline via Datatracker <[email-masked]> wrote:
> > I might recommend instead referring to RFC 6554 S4.2 for how to
> > handle RH3's if the node is also a RPL-aware router and say it MUST
> > drop the packet if segments left is non-zero and it's not a RPL-aware
> > router.
>
> > Related: I'd also recommend:
>
> > "It should just be noted that an incoming RH3 must be fully consumed,
> > or very carefully inspected."
>
> ->
>
> > "It should just be noted that an incoming RH3 MUST be fully
> > consumed."
>
> I think that Pascal and I, when we write the "carefully inspected", is
that we
> are imagining situations where the topology is a bit subtle.

Yes, I expected policies that would validate the right of a Leaf to
participate to a DODAG ,or to remap the information from the leaf (could be
the RPI, the opaque field in the EARO, or the 6-tuple) into an RPI.

> Perhaps there are firewalls involved.
> Perhaps a device has multiple interfaces (many radios for instance) and
the
> extra segments address the other interfaces.
>
> Also draft-ietf-anima-autonomic-control-plane uses storing mode, so never
> has
> RH3 headers, but imagine if it did.
>
> One could have a situation where the physical system containing one or
more
> layers of container was not the ultimate last hop from a logical point of
view.
> Rather than inner container was. So, it's all the same stack actually. In
that
> case, an optimization might be to process more than one segment in that
> stack.
> (The ANIMA ACP definitely supports having VMs and containers inside
> routers)
>
> So, I can live with your suggestion, because in my case above, we can
argue
> that it's still "consumed"
>
> > * I'm confused by the use of "consumed" here. Is the final RH3 entry
> > RUL's address? I guess you could say RH penultimate hop "consumes" the
> > header because the ultimate destination address is put in the header DA
> > field. Seems a bit odd though.
>
> Yes, that's what we mean.

Yes, as I said in my response I thought it was quite common. I'm surprised
to find little art to quote.

> Once that ultimate destination is in the DA, then the RH3 is a dummy, but
one
> we are aren't supposed to remove.
>
> > I assume 6LR_n gets RUL's address from the last segment in RH3.
>
> > "Consumed" means segments left == 0, I guess? I suppose should have
> > picked up on this terminology when it was first used in Section 2.
> > Maybe clarify what it means in that section (2)?
>
> Yes.

Cool, we're good!

Pascal
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Ines Robles <[email-masked]>
Date: Wed, 6 Jan 2021 03:17:32 +0200

Hi,

Some updates were done in the document through github, still we are
reviewing if all the requested changes are completed.

Apologizes for the delay,

Ines.

On Tue, Jan 5, 2021 at 10:25 PM Alvaro Retana <[email-masked]>
wrote:

> > layers of container was not the ultimate last hop from a logical point
> of view.
> > Rather than inner container was. So, it's all the same stack actually.
> In that
> > Once that ultimate destination is in the DA, then the RH3 is a dummy,
> but one

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 6 Jan 2021 18:04:01 +0000

Hello Alvaro

The history of changes is available here:
https://github.com/roll-wg/useofrplinfo/commits/master/roll-useofrplinfo.xml

For this discussion I proposed the following change: https://github.com/roll-wg/useofrplinfo/pull/10/commits/33c5a523c88e5d603558d9f9c25e613ac8984776

I made a pull request, if Ines is OK with the change;

You all have a great year!

Pascal

From: Ines Robles <mariainesrobles=[email-masked]>
Sent: mercredi 6 janvier 2021 02:18
To: Routing Over Low power and Lossy networks <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; Erik Kline <[email-masked]>
Subject: Re: [Roll] Erik Kline's Discuss on draft-ietf-roll-useofrplinfo-42: (with DISCUSS and COMMENT)

Hi,

Some updates were done in the document through github, still we are reviewing if all the requested changes are completed.

Ines.

On Tue, Jan 5, 2021 at 10:25 PM Alvaro Retana <[email-masked]<mailto:[email-masked]>> wrote:
Hi!

Where are we with this?   It is not clear whether we need to update the document or if we’re all agreeing. ;-)

Erik/Pascal?

Thanks!

Alvaro.

On December 18, 2020 at 10:42:24 AM, Pascal Thubert (pthubert) (pthubert=[email-masked]<mailto:pthubert=[email-masked]>) wrote:
Hello Michael and all:

> From: Roll <[email-masked]<mailto:[email-masked]>> On Behalf Of Michael Richardson
> To: Erik Kline <[email-masked]<mailto:[email-masked]>>; Routing Over Low power and Lossy
> networks <[email-masked]<mailto:[email-masked]>>
> Subject: Re: [Roll] Erik Kline's Discuss on draft-ietf-roll-useofrplinfo-42: (with
> DISCUSS and COMMENT)
>
>
> Erik Kline via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
> I think that Pascal and I, when we write the "carefully inspected", is that we

Yes, I expected policies that would validate the right of a Leaf to participate to a DODAG ,or to remap the information from the leaf (could be the RPI, the opaque field in the EARO, or the 6-tuple) into an RPI.

> Perhaps a device has multiple interfaces (many radios for instance) and the
> One could have a situation where the physical system containing one or more
> layers of container was not the ultimate last hop from a logical point of view.
> Rather than inner container was. So, it's all the same stack actually. In that
> So, I can live with your suggestion, because in my case above, we can argue

Yes, as I said in my response I thought it was quite common. I'm surprised to find little art to quote.

> Once that ultimate destination is in the DA, then the RH3 is a dummy, but one

Cool, we're good!

Pascal
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/roll

---

From: Ines Robles <[email-masked]>
Date: Sun, 10 Jan 2021 21:11:04 +0200

Dear Erik,

Thank you very much for your comments and suggestions, in version 43
(diff)  [Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-43] we added
a definition of consumed RH:

New text:
    Consumed: A Routing Header is consumed when the Segments Left field
    is zero, which indicates that the destination in the IPv6 header is
    the final destination of the packet and that the hops in the Routing
    Header have been traversed.

Please let us know if this addresses your concern.

Thank you again,

Ines, Michael and Pascal.

---

From: Ines Robles <[email-masked]>
Date: Fri, 15 Jan 2021 19:29:55 +0200

Dear Erik,

version 44 recently published [
https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-44.txt]

1- Extends the definition of Flag Day:

Flag Day: A Flag Day is caused when a network is reconfigured in a
way that nodes running the older configuration can not communicate
with nodes running the new configuration.  For instance, when the
ARPANET changed from IP version 3 to IP version 4 on January 1, 1983
([RFC0801]).  In the context of this document, a switch from RPI
Option Type (0x63) and Option Type (0x23) presents as a disruptive
changeover.  In order to reduce the amount of time for such a
changeover, Section 4.1.3 provides a mechanism to allow nodes to be
incrementally upgraded.

2-  Clarifies in Security Considerations the RH3 header usage

"The RH3 header usage described here can be abused in equivalent ways.
   An external attacker may form a packet with an RH3 that is not fully
   consumed and encapsulate it to hide the RH3 from intermediate nodes
   and disguise the origin of traffic.  As such, the attacker's RH3
   header will not be seen by the network until it reaches the
   destination, which will decapsulate it.  As indicated in section 4.2
   of [RFC6554] <https://tools.ietf.org/html/rfc6554#section-4.2>, RPL
routers are responsible for ensuring that an SRH is
   only used between RPL routers.  As such, if there is an RH3 that is
   not fully consumed in the encapsulated packet, the node that
   decapsulates it MUST ensure that the outer packet was originated in
   the RPL domain and drop the packet otherwise.

   Also, as indicated by section 2 of [RFC6554]
<https://tools.ietf.org/html/rfc6554#section-2>, RPL Border Routers
"do
   not allow datagrams carrying an SRH header to enter or exit a RPL
   routing domain".  This sentence must be understood as concerning non-
   fully-consumed packets.  A consumed (inert) RH3 header could be
   present in a packet that flows from one LLN, crosses the Internet,
   and enters another LLN.  As per the discussion in this document, such
   headers do not need to be removed.  However, there is no case
   described in this document where an RH3 is inserted in a non-storing

   network on traffic that is leaving the LLN, but this document should
   not preclude such a future innovation.

   In short, a packet that crosses the border of the RPL domain MAY
   carry and RH3, and if so, that RH3 MUST be fully consumed."

Please let us know if this address your concern.

Thank you very much in advance,

Ines, Pascal and Michael.

On Sun, Jan 10, 2021 at 9:11 PM Ines Robles <[email-masked]>
wrote:

> https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-43] we
> added a definition of consumed RH:
>
> New text: