Subject: [Roll] Following up on seq Counter to protect the config option and others

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 14 Oct 2019 16:56:23 +0000

Dear all :

At the interim today we refined the idea of a Sequence counter in a DIO that increments when there is a change in a global option.
For the lack of an acronym that results in SEAL, I'm using the RPL Configuration State Sequence (RCSS) for now.
This concerns options that are fully set by the root and propagated unchanged. Seems that this means at this time:

   1.  The Route Information Option (RIO)
   2.  The Prefix Information Option (PIO)
   3.  The DODAG Configuration Option (DCO)
   4.  The Extended MOP Option (MOPex)
   5.  The Global Capabilities Option (GCO)

Note that this also means that the capabilities have to be split between the parent capabilities (not protected) and the network-wide that are (item 5 above).
The alternate is that the RCSS covers everything a parent advertises in which case it is not set by the root but by individual parents.

Or do we need 2 counters?

Pascal

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 15 Oct 2019 03:47:18 +0000

[RJ] I think RCSS can be handled by individual parents (similar to DTSN in storing MOP). The only problem would be that additional memory i.e., one byte per parent would be required in this case. May not be a big problem since the parent set is limited in size.

[RJ] IMO, This won't be a good option, memory-wise or handling-wise.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 15 Oct 2019 09:28:58 +0200

On Mon, Oct 14, 2019 at 6:57 PM Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Dear all :
>
> *   At the interim today we refined the idea of a Sequence counter in a
> DIO that increments when there is a change in a global option.*
>

Ok, but I think the incrimination to be different per different
changes  (changes possibilities with different increment number, so any
change case can be identified and corrected)

* For the lack of an acronym that results in SEAL, I’m using the RPL
> Configuration State Sequence (RCSS) for now. This concerns options that are
> fully set by the root and propagated unchanged. Seems that this means at
> this time:        1.  The Route Information Option (RIO)    2.  The Prefix
> Information Option (PIO)    3.  The DODAG Configuration Option (DCO)    4.
> The Extended MOP Option (MOPex)    5.  The Global Capabilities Option (GCO)
> *
>

options can be more or less depending on the LLN

> *  Note that this also means that the capabilities have to be split
> between the parent capabilities (not protected) and the network-wide that
> are (item 5 above). The alternate is that the RCSS covers everything a
> parent advertises in which case it is not set by the root but by individual
> parents.   Or do we need 2 counters? *
>

one counter per parent.

AB

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 15 Oct 2019 08:45:33 +0000

Hello Rahul

We want to protect a global configuration with a sequence set by the root because the root is authoritative in them.
Why? A node may receive different levels of config from different parents and one of them may be back level. The node needs a freshness indication. It may want a signature in the future.
=> We need to split the capabilities that go in the DIO and that are protected by the RCSS from the rest and think about how we protect that rest.

Makes sense?

Pascal

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: mardi 15 octobre 2019 05:47
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] Following up on seq Counter to protect the config option and others

---

From: Rahul Jadhav <[email-masked]>
Date: Tue, 15 Oct 2019 09:31:39 +0000

Makes sense?

[RJ] Yes, the problem with RCSS been controlled by individual parents is that it is not possible to know if the root caps are changed. And we certainly need that. So we need to split the caps and use two counters?

Note that this also means that the capabilities have to be split between the parent capabilities (not protected) and the network-wide that are (item 5 above)..

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Oct 2019 14:48:28 +0200

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > At the interim today we refined the idea of a Sequence counter in a DIO
    > that increments when there is a change in a global option. 
    > For the lack of an acronym that results in SEAL, I'm using the RPL
    > Configuration State Sequence (RCSS) for now.
    
I came up with:

  Special Elided Attribute Lollipop = SEAL.
or
  Sequence of Elided Attributes Lollipop = SEAL.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 16 Oct 2019 13:43:21 +0000

Getting close :)

Lollipop is no fun

Litigator maybe?

Regards,

Pascal

> Le 16 oct. 2019 à 14:48, Michael Richardson <[email-masked]> a écrit :
> 
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll