[Roll] RPL secure messages

Rahul Jadhav <rahul.ietf@gmail.com> Fri, 02 October 2020 05:55 UTC

Return-Path: <rahul.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395303A0E63 for <roll@ietfa.amsl.com>; Thu, 1 Oct 2020 22:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtinHKOPtts3 for <roll@ietfa.amsl.com>; Thu, 1 Oct 2020 22:55:46 -0700 (PDT)
Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3F063A0E58 for <roll@ietf.org>; Thu, 1 Oct 2020 22:55:45 -0700 (PDT)
Received: by mail-ej1-x630.google.com with SMTP id u8so304682ejg.1 for <roll@ietf.org>; Thu, 01 Oct 2020 22:55:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yZa83N419iwmL0PEi6/I+TyRSllSsEF2NdUvKz2J4nA=; b=qDJEfx++nt3f1ffJyjaN3rEwGvVSwXbtyAvMP1BH1+L88ITQExNCRtvQ/8b5nINH4X OOv2kBs3bUKEOTg067xjKnd4bwMwOCVQt6s3U71uVMg6WlpahHuMjmwcxxJoBvbPaZLG GYyS6094h+2WE6BWE8bQyu2pkvwBqin/j5eyR80535iH6MEG8+AIPYI2JT8/XiHgD0iv NIw6PyCEJO1OE/tumXNDYgX9osdzPjFqo8UIRcE7BzglcEZGnD7AX4OXr1lUEg+QemyC FiOy8Axu4yiq5LxFHjZvL10JLZaRK4euLwEkpzTxM8iLCYbauP4Esvo6HWoJg8MSPl2q mGlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yZa83N419iwmL0PEi6/I+TyRSllSsEF2NdUvKz2J4nA=; b=A8f6aiJ+uki0TXMhvWyvAKEJ0xbB9yMmLS0yUWPX6rxBdQO4UpC8nPEwAE7xvK8OSD HrqujgooLkNb065sLFacV72XKRXGmpVGFim5q++9/nRN9NT3m+SYVyEm1z/3hAtxkJEy bB00awu6i1PRukQ3e6nQLqmeY8Ntpb4176rEeejgkYaI6M84mv5+qQV1MRHFjG/7PLHB EgCDxMdQ1VUk3O4XF6eFDuMQNsvI5a+RiEbLGeF5dFeY7Ps+jV3AhAqiFIgPk/iszKaM 5p9EMSau2vBzaMA+eCeKxA3WShhlxKGeutBge+VOi5IwCMTK6508JEyl5raj/6AW8XNM Jlpg==
X-Gm-Message-State: AOAM532KacR5G0TzecjspfRW2p1bBdcehJjUoPBA2wNAO5bC+S1uMPwF f/WS8bsXlJ+CuNCXqMwUNB7JUqiozrNcp5odw5C8QhgU5i+lGQ==
X-Google-Smtp-Source: ABdhPJxHRy4jE1JhNjxzSXEcZOCsUDtFHxFTrAm10UN5xr8sGtWKS2dGoq9Bs458+lwf61u+QYiYsVglsNDyiCI6tSg=
X-Received: by 2002:a17:906:7d52:: with SMTP id l18mr561197ejp.220.1601618143672; Thu, 01 Oct 2020 22:55:43 -0700 (PDT)
MIME-Version: 1.0
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Fri, 02 Oct 2020 11:25:32 +0530
Message-ID: <CAO0Djp19_3AXpQY5poxA_-d6kjmpuxi1NowCqc2FZNoOb2Zm4g@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000084fd1005b0a9c83e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/2NL8KrzFKpWpooLq1ROwgL_jNYY>
Subject: [Roll] RPL secure messages
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Oct 2020 05:55:47 -0000

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