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

From: Erik Kline via Datatracker <[email-masked]>
Date: Tue, 15 Dec 2020 21:46:54 -0800

Erik Kline has entered the following ballot position for
draft-ietf-roll-useofrplinfo-42: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[ section 12 ]

* Ignoring an invalid RH3 header by the end host (I'm assuming this
  means that segments left > 0) doesn't specify whether the packet
  should be processed (ignore the RH) or the whole packet should be
  ignored.

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[[ comments ]]

[ section 8.1.3 ]

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

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

[[ questions ]]

[ section 4.1.3 ]

* To be clear, the DODAG Configuration option flags being updated
  is the one in 6550 S6.7.6?

[ section 9 ]

* This the final paragraph strictly true?  It seems that in some situations
  in section 7 full-encapsulated packets can arrived at the RUL with all
  RPL artifacts removed.  Again: in certain situations.

[[ nits ]]

[ section 1.1 ]

* "uses cases" -> "use cases"

[ section 4.1.3 ]

* "when a node joins to a network will know" ->
  "when a node joins to a network it will know", I think

* "MUST be initialize to zero" -> "MUST be initialized to zero"

  (Separately: if this is quoting text from 6.7.6, then it's not
   exactly a direct quote.)

[ section 6 ]

* "while adding significant in the code" ->
  "while adding significant <noun|noun phrase> in the code", I think

[ section 9 ]

* "traffic originating from..." ->
  "Traffic originating from..."

[ section 12 ]

* "if attack" -> "if the attack" or "if an attack"

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 Dec 2020 12:38:13 +0000

Hello Erik

Many thanks for your review!

On the one hand, this spec applies to RPL routers so implicitly it can dictate what a RAN does but not what a RPL unaware node does.

On the other hand, RFC 8200 has:
"
   If, while processing a received packet, a node encounters a Routing
   header with an unrecognized Routing Type value, the required behavior
   of the node depends on the value of the Segments Left field, as
   follows:

      If Segments Left is zero, the node must ignore the Routing header
      and proceed to process the next header in the packet, whose type
      is identified by the Next Header field in the Routing header.

      If Segments Left is non-zero, the node must discard the packet and
      send an ICMP Parameter Problem, Code 0, message to the packet's
      Source Address, pointing to the unrecognized Routing Type.
"

So maybe for RPL Unaware Nodes, we do node need to be normative, just mention the above as the generic protection for all RHs?

>   "It should just be noted that an incoming RH3 MUST be fully consumed."

By consumed we mean segment left == 0; would you have a better term? 

On the side of this discuss and for consistency, draft-ietf-roll-unaware-leaves says:

"
                                                                [USEofRPLinfo] expects the
   RUL to support the basic "IPv6 Node Requirements" [RFC8504].  In
   particular the RUL is expected to ignore the RPL artifacts that are
   either consumed or not applicable to a host.

"

Based on your comments  I changed that text in -27 to 

"
                                                                       [USEofRPLinfo] expects the
   RUL to support the basic "IPv6 Node Requirements" [RFC8504] and in
   particular the mandates in Sections 4.2 and 4.4 of [RFC8200].  As
   such, the RUL is expected to ignore the RPL artifacts that may be
   left over, either an SRH with zero Segments Left or a RPL Option in
   the Hop-by-Hop Header, which can be skipped when not recognized, see
   Section 5."

draft-ietf-roll-unaware-leaves also indicates:

"
5.4.  Support of the Routing Header

   A RUL is expected to process an unknown Routing Header Type as
   prescribed by section 4.4 of [RFC8200].  This implies that the Source
   Routing Header with a Routing Type of 3 [RFC6554] is ignored when the
   Segments Left is zero.
"

That would be good, I thought "consumed" was more common than it usually appears to be, at least in the RFCs.

Keep safe;

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Dec 2020 13:01:34 -0500

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.

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

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

    > 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.
Once that ultimate destination is in the DA, then the RH3 is a dummy, but one
we are aren't supposed to remove.

    > Maybe clarify what it means in that section (2)?

Yes.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Erik Kline <[email-masked]>
Date: Wed, 16 Dec 2020 13:26:25 -0800

> (The ANIMA ACP definitely supports having VMs and containers inside

(trying to respond to both threads)

I guess, one way to look at it would be: for any given node, receiving a
packet with an RH3 and segments left > 0, does the discussion here change
anything?  If the node is part of nested layers of networking it might do
what it's configured to do, and if it's a plain vanilla host it should
reject the packet.

If there's no behaviour change then perhaps we can just trim all the text
and point text elsewhre (I have a note from reading last night about
roll-unaware-leaves S5.4 being a possible landing spot for a pointer, as
Pascal mentioned above).

Thanks for the ongoing discussion!

> the

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Dec 2020 13:14:28 -0500

> what it's configured to do, and if it's a plain vanilla host it should

I think that Pascal might have had some extension in mind when he wrote the
"inspected" part.  Part of the reason for useofrplinfo was to make sure that
we actually understood all of the cases, and there were some surprises among
a few, and that partly led to unaware-leaves being written.

so, we'll stick with "consumed"

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 18 Dec 2020 15:41:39 +0000

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

> 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.
> So, I can live with your suggestion, because in my case above, we can argue
> that it's still "consumed"
> 

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

>     > Maybe clarify what it means in that section (2)?

Cool, we're good!

Pascal