pith. sign in

arxiv: 1906.12143 · v1 · pith:ETPRGQRYnew · submitted 2019-06-28 · 💻 cs.NI

A DTLS Abstraction Layer for the Recursive Networking Architecture in RIOT

M. Aiman Ismail , Thomas C. Schmidt This is my paper

Pith reviewed 2026-05-25 13:33 UTC · model grok-4.3

classification 💻 cs.NI
keywords DTLSRIOTIoTabstraction layersecure communicationcredential managementnetworking stackconstrained devices
0
0 comments X

The pith

RIOT gains a DTLS abstraction layer that swaps underlying security implementations with only a few lines of code.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces a new layer inside the RIOT networking architecture that provides secure DTLS communication for applications on constrained IoT devices. This layer serves as a modular interface over different DTLS libraries so that the chosen implementation can be exchanged by editing only a few lines. The work also adds credman, a dedicated module that handles credentials for (D)TLS sessions. A reader would care because many IoT devices still transmit over insecure channels that invite eavesdropping or tampering, and a clean abstraction reduces the cost of adopting or updating secure stacks.

Core claim

The paper presents a new layer in the RIOT networking architecture to seamlessly integrate secure communication between applications using DTLS. The layer acts as a modular abstraction layer of the different DTLS implementations, enabling swapping of the underlying implementation with just a few lines of code. This paper also introduces credman, a new module to manage credentials used for (D)TLS connections.

What carries the argument

The DTLS abstraction layer placed inside the recursive networking architecture together with the credman credential-management module.

If this is right

  • Applications obtain DTLS protection without rewriting large parts of their networking code.
  • Different DTLS libraries can be tested or deployed by changing only the binding to the abstraction layer.
  • Credential handling is centralized in credman instead of being scattered across applications.
  • Secure channels become a standard, replaceable component of the RIOT stack rather than a custom add-on.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The design could let maintainers update to a faster or smaller DTLS library in future releases without touching every application.
  • Central credential storage may simplify audits for key leakage on devices that lack hardware security modules.
  • The same abstraction pattern might later be applied to other security protocols such as TLS or OSCORE inside RIOT.

Load-bearing premise

The abstraction layer can be added to RIOT's existing networking stack without unacceptable performance overhead or new security weaknesses on constrained devices.

What would settle it

Measure the added latency and memory use of the abstraction layer on a typical RIOT target board while successfully swapping one DTLS implementation for another by changing only a few lines of application code.

Figures

Figures reproduced from arXiv: 1906.12143 by M. Aiman Ismail, Thomas C. Schmidt.

Figure 1
Figure 1. Figure 1: RIOT networking stack RIOT module credman to manage the credentials used for the handshake. The remainder of this paper is structured as follows. In Section II, we introduce the existing networking stack of RIOT. In Sections III, we describe the new secure network stack, and Section IV presents experiments that assess its performance. In Section V, we draw conclusions with an outlook on future work. II. RI… view at source ↗
Figure 2
Figure 2. Figure 2: Architecture of sock dtls maintaining its modularity. We introduced two new modules credman and sock dtls (see [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗
Figure 5
Figure 5. Figure 5: Memory Usage but plainly uses RIOT UDP sock API sock udp to transmit the packets and acts as a controlling baseline. The test was setup as follows unless stated otherwise. The server is instantiated to listen for new connections and receives packet from clients. For each received packet, the payload size is logged into a file. On the client side, two metrics are measured: the time taken to process a packet… view at source ↗
Figure 4
Figure 4. Figure 4: Average Goodput As for the DTLS client, the first two steps are the same as for the server followed by 3) Establish session with a DTLS server 4) Start sending and receiving datagram packets IV. EXPERIMENTS AND EVALUATION We are now ready to validate our concept and assess the performance of our implementation. We compared sock dtls with tinyDTLS and sock udp and examine the metrics CPU overhead and goodpu… view at source ↗
read the original abstract

On the Internet of Things (IoT), devices continuously communicate with each other, with a gateway, or other Internet nodes. Often devices are constrained and use insecure channels for their communication, which exposes them to a selection of attacks that may extract sensitive pieces of information or manipulate dialogues for the purpose of sabotaging. This paper presents a new layer in the RIOT networking architecture to seamlessly integrate secure communication between applications using DTLS. The layer acts as a modular abstraction layer of the different DTLS implementations, enabling swapping of the underlying implementation with just a few lines of code. This paper also introduces credman, a new module to manage credentials used for (D)TLS connections.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

3 major / 2 minor

Summary. The paper presents a DTLS abstraction layer integrated into RIOT's recursive networking architecture. This layer provides a modular interface over multiple DTLS implementations, allowing the underlying library to be swapped with only a few lines of code. The work also introduces credman, a credential-management module for (D)TLS connections on constrained IoT devices.

Significance. If the abstraction integrates without material overhead and preserves security properties, the contribution would simplify secure communication development in RIOT by enabling backend flexibility. The design description itself is a concrete engineering artifact, but the absence of any runtime, memory, or security measurements prevents assessment of whether the layer meets the practical requirements stated in the motivation.

major comments (3)
  1. [Description of the abstraction layer (around the API and integration discussion)] The central claim that the abstraction layer enables swapping of DTLS implementations 'with just a few lines of code' is unsupported by any code examples, API usage traces, or integration snippets. Without such evidence the modularity assertion remains unverified.
  2. [Missing evaluation] No evaluation section, table, or figure reports code-size, RAM, or handshake-latency deltas on representative constrained hardware (e.g., Cortex-M). These metrics are load-bearing for the claim that the layer integrates cleanly into RIOT without unacceptable overhead.
  3. [credman and security discussion] The manuscript supplies no security argument or threat-model analysis showing that the indirection and credman module preserve the security guarantees of each DTLS backend or avoid introducing new attack surfaces on constrained devices.
minor comments (2)
  1. [Abstract] The abstract states the existence of the layer but does not preview any concrete API or integration cost; a short illustrative code fragment would improve clarity.
  2. [Architecture overview] Notation for the recursive networking stack and the placement of the new layer relative to existing modules is introduced without a diagram or explicit layering figure.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive and detailed feedback. The comments highlight areas where the manuscript can be strengthened with additional evidence and analysis. We address each major comment below and indicate the planned revisions.

read point-by-point responses

  1. Referee: [Description of the abstraction layer (around the API and integration discussion)] The central claim that the abstraction layer enables swapping of DTLS implementations 'with just a few lines of code' is unsupported by any code examples, API usage traces, or integration snippets. Without such evidence the modularity assertion remains unverified.

    Authors: We agree that concrete examples are needed to substantiate the modularity claim. In the revised manuscript we will add code snippets and API usage traces demonstrating how a DTLS backend can be swapped with only a few lines of code, including integration with the recursive networking stack. revision: yes

  2. Referee: [Missing evaluation] No evaluation section, table, or figure reports code-size, RAM, or handshake-latency deltas on representative constrained hardware (e.g., Cortex-M). These metrics are load-bearing for the claim that the layer integrates cleanly into RIOT without unacceptable overhead.

    Authors: The current manuscript emphasizes the architectural design and integration approach. To address the request for quantitative validation, the revision will include a new evaluation section with measurements of code size, RAM footprint, and handshake latency on Cortex-M hardware, comparing the abstraction layer against direct backend usage. revision: yes

  3. Referee: [credman and security discussion] The manuscript supplies no security argument or threat-model analysis showing that the indirection and credman module preserve the security guarantees of each DTLS backend or avoid introducing new attack surfaces on constrained devices.

    Authors: We acknowledge the value of an explicit security discussion. The revised manuscript will add a dedicated section presenting a threat model and arguing that the abstraction layer and credman preserve the security properties of the chosen DTLS backends while introducing no new attack surfaces beyond those already present in the underlying libraries. revision: yes

Circularity Check

0 steps flagged

No circularity: purely descriptive software design with no derivations or fitted claims

full rationale

The manuscript describes a new DTLS abstraction layer and credman module for RIOT. It contains no equations, no parameter fitting, no predictions derived from inputs, and no self-citation chains invoked to justify uniqueness or force a result. The central contribution is an engineering artifact (API design and integration) whose correctness is evaluated externally via implementation and testing, not by internal reduction to its own definitions. This matches the default case of a self-contained descriptive paper.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 2 invented entities

The paper introduces two new software entities whose correctness and performance rest on unstated assumptions about DTLS suitability for IoT and the feasibility of a thin abstraction without side effects.

axioms (1)
  • domain assumption DTLS is an appropriate security protocol for constrained IoT devices communicating over insecure channels.
    Invoked implicitly by the choice to build a DTLS layer rather than another protocol.
invented entities (2)
  • DTLS abstraction layer no independent evidence
    purpose: Provide a modular interface to multiple DTLS implementations inside RIOT networking stack
    New software component introduced to enable swapping of DTLS libraries.
  • credman no independent evidence
    purpose: Manage credentials for (D)TLS connections
    New module introduced to handle credential storage and retrieval.

pith-pipeline@v0.9.0 · 5640 in / 1189 out tokens · 25684 ms · 2026-05-25T13:33:43.702498+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

12 extracted references · 12 canonical work pages · 1 internal anchor

  1. [1]

    write newline

    " write newline "" initialize.prev.this.status FUNCTION begin.bib " write newline preamble empty 'skip preamble write newline if " thebibliography " longest.label * " " * write newline " [1] #1 " write newline " url@samestyle " write newline " " write newline " [2] #2 " write newline " =0pt " write newline " " ALTinterwordstretchfactor * " " * write newli...

    work page

  2. [2]

    11em plus .33em minus .07em 4000 4000 100 4000 4000 500 `\.=1000 = #1 \@IEEEnotcompsoconly \@IEEEcompsoconly #1 * [1] 0pt [0pt][0pt] #1 * [1] 0pt [0pt][0pt] #1 * \| ** #1 \@IEEEauthorblockNstyle \@IEEEcompsocnotconfonly \@IEEEauthorblockAstyle \@IEEEcompsocnotconfonly \@IEEEcompsocconfonly \@IEEEauthordefaulttextstyle \@IEEEcompsocnotconfonly \@IEEEauthor...

    work page

  3. [3]

    Rescorla and N

    E. Rescorla and N. Modadugu, `` Datagram Transport Layer Security Version 1.2 ,'' IETF, RFC 6347, January 2012

    work page 2012

  4. [4]

    Postel, `` User Datagram Protocol ,'' IETF, RFC 768, August 1980

    J. Postel, `` User Datagram Protocol ,'' IETF, RFC 768, August 1980

    work page 1980

  5. [5]

    Rescorla, `` The Transport Layer Security (TLS) Protocol Version 1.3 ,'' IETF, RFC 8446, August 2018

    E. Rescorla, `` The Transport Layer Security (TLS) Protocol Version 1.3 ,'' IETF, RFC 8446, August 2018

    work page 2018

  6. [6]

    u ndogan, O. Hahm, P. Kietzmann, M. Lenders, H. Petersen, K. Schleiser, T. C. Schmidt, and M. W \

    E. Baccelli, C. G \"u ndogan, O. Hahm, P. Kietzmann, M. Lenders, H. Petersen, K. Schleiser, T. C. Schmidt, and M. W \"a hlisch, `` RIOT: an Open Source Operating System for Low-end Embedded Devices in the IoT ,'' IEEE Internet of Things Journal, vol. 5, no. 6, pp. 4428--4440, December 2018. [Online]. Available: http://dx.doi.org/10.1109/JIOT.2018.2815038

    work page doi:10.1109/jiot.2018.2815038 2018

  7. [7]

    Connecting the World of Embedded Mobiles: The RIOT Approach to Ubiquitous Networking for the Internet of Things

    M. Lenders, P. Kietzmann, O. Hahm, H. Petersen, C. G \"u ndogan, E. Baccelli, K. Schleiser, T. C. Schmidt, and M. W \"a hlisch, `` Connecting the World of Embedded Mobiles: The RIOT Approach to Ubiquitous Networking for the Internet of Things ,'' Open Archive: arXiv.org, Technical Report arXiv:1801.02833, January 2018. [Online]. Available: https://arxiv.o...

    work page internal anchor Pith review Pith/arXiv arXiv 2018

  8. [8]

    u ndogan, P. Kietzmann, M. Lenders, H. Petersen, T. C. Schmidt, and M. W \

    C. G \"u ndogan, P. Kietzmann, M. Lenders, H. Petersen, T. C. Schmidt, and M. W \"a hlisch, `` NDN, CoAP, and MQTT: A Comparative Measurement Study in the IoT ,'' in Proc. of 5th ACM Conference on Information-Centric Networking (ICN). 1em plus 0.5em minus 0.4em New York, NY, USA: ACM, September 2018, pp. 159--171. [Online]. Available: https://conferences....

    work page 2018

  9. [9]

    IEEE 802.15 Working Group , `` IEEE Standard for Local and metropolitan area networks---Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) ,'' IEEE, New York, NY, USA, Tech. Rep. IEEE Std 802.15.4 --2011, Sep 2011

    work page 2011

  10. [10]

    Montenegro, N

    G. Montenegro, N. Kushalnagar, J. Hui, and D. Culler, `` Transmission of IPv6 Packets over IEEE 802.15.4 Networks ,'' IETF, RFC 4944, September 2007

    work page 2007

  11. [11]

    Shelby, K

    Z. Shelby, K. Hartke, and C. Bormann, `` The Constrained Application Protocol (CoAP) ,'' IETF, RFC 7252, June 2014

    work page 2014

  12. [12]

    Gerdes, O

    S. Gerdes, O. Bergmann, C. Bormann, G. Selander, and L. Seitz, `` Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE) ,'' IETF, Internet-Draft -- work in progress 01, March 2017

    work page 2017