Subject: [Roll] RPL secure messages

From: Rahul Jadhav <[email-masked]>
Date: Fri, 2 Oct 2020 11:25:32 +0530

Hello All,

During the interim, Pascal raised this point as to whether it is necessary
to have a secure message counter-part for every new message that is defined
in new drafts?

To put it in context, currently we have:
Code 0x00 -> DIS, 0x80 -> Secure DIS
Code 0x01 -> DIO, 0x81 -> Secure DIO ... so on for all other messages we
have a secure equivalent. Inadvertently, the MSB is reserved as a secure
bit (without explicitly stating so).

Problem is, there is no one out there using secure messages at RPL layer
(would be very happy to be proved wrong here). Most deployments depend on
L2 security for RPL messaging.

So given the context, is it necessary for new drafts to work on secure
messaging for new messages drafted?

My take is that given that the work required to specify secure messages is
not much, we should do it anyways for all new msgs.  In terms of saving
some codes, I believe we may not be able to save much since the
implementations might check the MSB to find if the message is secure or
not, thus non-secure messages may not be able to use that bit.
Also adding a new message code is much rare as compared to adding new
control options. Almost every new draft is adding a new control option but
very few are adding new message code.

However, we currently have two drafts DAO-Projection and Capabilities
defining new message codes, and hence this discussion may be relevant now.

Thoughts welcome.

Regards,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 2 Oct 2020 07:19:59 +0000

Hello Rahul

The effort to standardize is small. The effort to implement is high. By putting something in the standards we are writing now we are giving a sense that the function should be implemented, and that the secured model is here to stay. If we do not provide the secured version we are giving a sense that we are deprecating the function, and that it will be gone in RPLv2.

I asked during the capabilities discussion because that seems to be a RPLv2 function. So it seems exemplary to the case where we should not provide a secured version if we think that this will be gone with v2.

OTOH, the DAO projection is expected to operate in a RPLv1 environment. So the question is wide open there. For now, we do not have the secured alternative. Which gives a sense that we are on a deprecating path. This is where I see your argument apply best: if anyone needs the secured version, then it makes sense to add it even if RPLv2 deprecates later – and you’re welcome to contribute that text ; )

What do others think?

Pascal

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: vendredi 2 octobre 2020 07:56
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: [Roll] RPL secure messages

Hello All,

During the interim, Pascal raised this point as to whether it is necessary to have a secure message counter-part for every new message that is defined in new drafts?

To put it in context, currently we have:
Code 0x00 -> DIS, 0x80 -> Secure DIS
Code 0x01 -> DIO, 0x81 -> Secure DIO ... so on for all other messages we have a secure equivalent. Inadvertently, the MSB is reserved as a secure bit (without explicitly stating so).

Problem is, there is no one out there using secure messages at RPL layer (would be very happy to be proved wrong here). Most deployments depend on L2 security for RPL messaging.

So given the context, is it necessary for new drafts to work on secure messaging for new messages drafted?

My take is that given that the work required to specify secure messages is not much, we should do it anyways for all new msgs.  In terms of saving some codes, I believe we may not be able to save much since the implementations might check the MSB to find if the message is secure or not, thus non-secure messages may not be able to use that bit.
Also adding a new message code is much rare as compared to adding new control options. Almost every new draft is adding a new control option but very few are adding new message code.

However, we currently have two drafts DAO-Projection and Capabilities defining new message codes, and hence this discussion may be relevant now.

Thoughts welcome.

Regards,
Rahul

---

From: Michael Richardson <[email-masked]>
Date: Sat, 03 Oct 2020 22:31:23 -0400

Pascal Thubert \(pthubert\) <pthubert=[email-masked]> wrote:
    > The effort to standardize is small. The effort to implement is high. By
    > putting something in the standards we are writing now we are giving a
    > sense that the function should be implemented, and that the secured
    > model is here to stay. If we do not provide the secured version we are
    > giving a sense that we are deprecating the function, and that it will
    > be gone in RPLv2.

If we are honest, when we do RFC6550bis, we will deprecate all the secure
versions, as they were never implemented.
Until then, I am uncertain what to do.

The secure functions are not implementable without rather fast assymetric
crypto, and per-node certificates.  (i.e. onboarding).

{I said so back in 2010, and for my trouble wound up WG co-chair as punishment.}

Once we have capabilities, we could at that point, introduce secure versions
again :-)

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