[core] CORECONF Hackathon implementation feedback

Koen Zandberg <koen@bergzand.net> Tue, 07 November 2023 13:01 UTC

Return-Path: <koen@bergzand.net>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CDFFC18E181 for <core@ietfa.amsl.com>; Tue, 7 Nov 2023 05:01:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bergzand.net
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjXUbTgt9nEl for <core@ietfa.amsl.com>; Tue, 7 Nov 2023 05:01:02 -0800 (PST)
Received: from mail.bergzand.net (mail.bergzand.net [116.203.165.243]) by ietfa.amsl.com (Postfix) with ESMTP id 96E3BC1D470F for <core@ietf.org>; Tue, 7 Nov 2023 05:00:51 -0800 (PST)
Received: from [10.1.7.20] (185-227-75-229.dsl.cambrium.nl [185.227.75.229]) by mail.bergzand.net (Postfix) with ESMTPSA id 68F513967F7 for <core@ietf.org>; Tue, 7 Nov 2023 14:00:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bergzand.net; s=dkim; t=1699362049; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=W5rTGYijFdb7daNOatTmtr99gZC3KfsGHau8wxa5eXg=; b=MT/oIqyVR+v2AFIKvnYqatgQg5FW4sOb21mFd33B8PtXXUPJJQe7D4IYW2oKQ202YeP9TG cEfkIOlZ2vht/F3ipc+Kc1R1L0PQejmmwNBhW9Eor4WdjIlXJln+gq9N8YuNepr7RD/7PN wTdKkHoN8aAPO8kyWhV+ik8/wBK2+9yqPtImg1tOzqkDmp5YGE0NiwZhYynAx3fElpEGz7 Jc6VCSK640S5iuSwlsjHMqMQRLBPpirgZHZ8iQPgEersgNn80ULNH/HNvBc25SbLvLiuS+ SqBTJDKXjKDsT3aFbfr34tdjmbism2pkK3CdppqK0RKpzcleNUQTmOBO5yyVVg==
Message-ID: <2240e983-5da2-49a1-83ea-dd52deff8927@bergzand.net>
Date: Tue, 07 Nov 2023 14:00:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
From: Koen Zandberg <koen@bergzand.net>
To: core@ietf.org
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/ju1SSExnniBgBcVIsa8Xok927pI>
Subject: [core] CORECONF Hackathon implementation feedback
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2023 13:01:06 -0000

Hi all,

During the hackathon I had another opportunity to work on my 
implementation for CORECONF. So far nothing from the spec translates 
into anything hard to implement. Most of the feedback here is either 
clarification I think is needed in the draft or originates from the 
removal of GET and PUT interaction on the individual data node resources.

Terminology: Data node resource needs rephrasing as it doesn't map to a 
single CoAP resource anymore now that GET/PUT on individual coap 
resources is no longer in the spec.

- 3.5.{1,2}: Is multiple RPCs and actions in a single POST request 
allowed and should there be something defined around ordering and 
parallel execution be defined?

- 5.2.2: This section can be removed entirely as far as I can see.

One thing discussed during the hackathon was to remove GET and PUT as 
operations on the full datastore as those could be replaced with FETCH 
and IPATCH operating on SID 0, which would make SID 0 a special full 
datastore SID. From (my) implementation perspective this is trivial to 
implement. The only minor concern I have here is that a DOS or battery 
drain attack might be possible on a device via a FETCH with payload [0, 
0, 0…] in other words, request the full datastore multiple times. Given 
that any interaction with the datastore must be authenticated I don't 
see a large concern here and even then it should be easy to mitigate on 
the device side.

Cheers,

Koen Zandberg