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

[Ines Robles <[e-mail]>]

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 <[e-mail]>
wrote:

> 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.
>
> On Fri, Dec 18, 2020 at 5:42 PM Pascal Thubert (pthubert) <pthubert=
> [e-mail]> wrote:
>
>> Hello Michael and all:
>>
>> > -----Original Message-----
>> > From: Roll <[e-mail]> On Behalf Of Michael Richardson
>> > Sent: mercredi 16 décembre 2020 19:02
>> > To: Erik Kline <[e-mail]>; Routing Over Low power and Lossy
>> > networks <[e-mail]>
>> > Subject: Re: [Roll] Erik Kline's Discuss on
>> draft-ietf-roll-useofrplinfo-42: (with
>> > DISCUSS and COMMENT)
>> >
>> >
>> > Erik Kline via Datatracker <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/roll
>>
>