<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.22 (Ruby 3.0.2) -->
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-toutain-lpwan-access-control-00" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.16.0 -->
  <front>
    <title abbrev="SCHC AC">SCHC Rule Access Control</title>
    <seriesInfo name="Internet-Draft" value="draft-toutain-lpwan-access-control-00"/>
    <author initials="A." surname="Minaburo" fullname="Ana Minaburo">
      <organization>Acklio</organization>
      <address>
        <postal>
          <street>1137A avenue des Champs Blancs</street>
          <city>35510 Cesson-Sevigne Cedex</city>
          <country>France</country>
        </postal>
        <email>ana@ackl.io</email>
      </address>
    </author>
    <author initials="L." surname="Toutain" fullname="Laurent Toutain">
      <organization>Institut MINES TELECOM; IMT Atlantique</organization>
      <address>
        <postal>
          <street>2 rue de la Chataigneraie</street>
          <street>CS 17607</street>
          <city>35576 Cesson-Sevigne Cedex</city>
          <country>France</country>
        </postal>
        <email>Laurent.Toutain@imt-atlantique.fr</email>
      </address>
    </author>
    <author initials="I." surname="Martinez" fullname="Ivan Martinez">
      <organization>Institut MINES TELECOM; IMT Atlantique</organization>
      <address>
        <postal>
          <street>2 rue de la Chataigneraie</street>
          <street>CS 17607</street>
          <city>35576 Cesson-Sevigne Cedex</city>
          <country>France</country>
        </postal>
        <email>ivan-marino.martinez-bolivar@imt-atlantique.fr</email>
      </address>
    </author>
    <date year="2023" month="February" day="14"/>
    <workgroup>lpwan Working Group</workgroup>
    <abstract>
      <t>The framework for SCHC defines an abstract view of the rules, formalized with through a YANG Data Model. In its original description rules are static and share by 2 entities. The use of YANG authorizes rules to be uploaded or modified in a SCHC instance and leads to some possible attacks, if the changes are not controlled. This document summarizes some possible attacks and define augmentation to the existing Data Mode, to restrict the changes in the rule.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction">
      <name>Introduction</name>
    </section>
    <section anchor="attack-scenario">
      <name>Attack scenario</name>
      <t>A LWM2M device, under control of an attacker, sends some management messages to modify the SCHC rules in core in order to direct the traffic to another application. This can be either to participate to a DDoS attack or to send sensible information to another application.</t>
      <t>SCHC rules are defined for a specific traffic. An attacker changes en element (for instance, the dev UDP port number) and therefore no rule matches the traffic, the link may be saturated by no-compressed messages.</t>
    </section>
    <section anchor="yang-access-control">
      <name>YANG Access Control</name>
      <t>YANG language allows to specify read only or read write nodes. NACM <xref target="RFC8341"/> extends this by allowing users or group od users to perform specific actions.</t>
      <t>This granularity do not fit this the rule model. For instance, the goal is not to allow all the field-id leaves to be modified. The objective is to allow a specific rule entry to be changed and therefore some of the leaves to be modified. For instance an entry with field-id containing Uri-path may have his target-value modified, as in the same rule, the entry regarding the app-prefix should not be changed.</t>
      <t>The SCHC access control augments the YANG module defined in <xref target="I-D.ietf-lpwan-schc-yang-data-model"/> to allow a remote entity to manipulate the rules. Several levels are defined.</t>
      <ul spacing="normal">
        <li>in the set of rules, it authorizes or not a new rule to be added .</li>
        <li>in a compression rule, it allows to add or remove field descriptions.</li>
        <li>in a compression rule, it allows to modify some elements of the rule, such as the target-value, the matching-operator or/and the comp-decomp-action and associated values.</li>
        <li>in a fragmentation rule, it allows to modify some parameters.</li>
      </ul>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <reference anchor="RFC8824">
        <front>
          <title>Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)</title>
          <author fullname="A. Minaburo" initials="A." surname="Minaburo">
            <organization/>
          </author>
          <author fullname="L. Toutain" initials="L." surname="Toutain">
            <organization/>
          </author>
          <author fullname="R. Andreasen" initials="R." surname="Andreasen">
            <organization/>
          </author>
          <date month="June" year="2021"/>
          <abstract>
            <t>This document defines how to compress Constrained Application Protocol (CoAP) headers using the Static Context Header Compression and fragmentation (SCHC) framework. SCHC defines a header compression mechanism adapted for Constrained Devices. SCHC uses a static description of the header to reduce the header's redundancy and size. While RFC 8724 describes the SCHC compression and fragmentation framework, and its application for IPv6/UDP headers, this document applies SCHC to CoAP headers. The CoAP header structure differs from IPv6 and UDP, since CoAP uses a flexible header with a variable number of options, themselves of variable length. The CoAP message format is asymmetric: the request messages have a header format different from the format in the response messages. This specification gives guidance on applying SCHC to flexible headers and how to leverage the asymmetry for more efficient compression Rules.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8824"/>
        <seriesInfo name="DOI" value="10.17487/RFC8824"/>
      </reference>
      <reference anchor="RFC8341">
        <front>
          <title>Network Configuration Access Control Model</title>
          <author fullname="A. Bierman" initials="A." surname="Bierman">
            <organization/>
          </author>
          <author fullname="M. Bjorklund" initials="M." surname="Bjorklund">
            <organization/>
          </author>
          <date month="March" year="2018"/>
          <abstract>
            <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability.  There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.  This document defines such an access control model.</t>
            <t>This document obsoletes RFC 6536.</t>
          </abstract>
        </front>
        <seriesInfo name="STD" value="91"/>
        <seriesInfo name="RFC" value="8341"/>
        <seriesInfo name="DOI" value="10.17487/RFC8341"/>
      </reference>
      <reference anchor="I-D.ietf-lpwan-schc-yang-data-model">
        <front>
          <title>Data Model for Static Context Header Compression (SCHC)</title>
          <author fullname="Ana Minaburo" initials="A." surname="Minaburo">
            <organization>Acklio</organization>
          </author>
          <author fullname="Laurent Toutain" initials="L." surname="Toutain">
            <organization>Institut MINES TELECOM; IMT Atlantique</organization>
          </author>
          <date day="9" month="October" year="2022"/>
          <abstract>
            <t>   This document describes a YANG data model for the SCHC (Static
   Context Header Compression) compression and fragmentation rules.

   This document formalizes the description of the rules for better
   interoperability between SCHC instances either to exchange a set of
   rules or to modify some rules parameters.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-lpwan-schc-yang-data-model-21"/>
      </reference>
    </references>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>TBD</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>TBD</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA81WTXPbNhC981fsTA5pO6ZqOx9O1UsUOUk9Y7md2JlMTx2I
WFFoSEAFQNmKJ/+9bwFSYj46TW/1eCQSBBdv3+57q7IsixCV1X+oxlmeUvQd
F2bj01WIp8fHPx2fFtpVVrV4rL1axTK6Lipjy2Zzq2ypqopDKCtno3dNeXxc
VCpOKURdbMy0IAq71vMqTOnhjsNDWXA+frYSvani4b5y7UaNF6KrhpsimtgA
y/X8lzm96RqmWUJA84ygUMul522/YTYvbuspJaj0zvn3xtb02rtuU6gurp2f
FiUZCyyzCS2MVcvOOxyY851ZNV50HqFm1fvGuAyaGRhPTh6dzUht2XZMmgFk
rdpNoBeNslWQbEzcTenRkycnxzQHUmfLa96a2jJuNd+lhDuAx65XHi8xVrhV
ppmSsuq5wokTHNkDvZzQTa7AHuel6jzbOFpPUC9sAFldpMXF1ctrunl5+XL+
6+Jnuljc0CwCXjR/dXxIBVclnZJPeVCjJBPEA1CvDKen82s6OXt6fDZO6+zp
f06rBzzpAT83bSzVHtFk5YdkL1AV5aOx/GGf7cUWtRyt/s9zNYBbtsob6yZt
j7pcugbr/svEqbDOtyqaLQvGN6/mz56dPh4uHz0+kcuL8nxiOK56CYZqXZU7
ZetSI4eydZqbaWHsahwJ//goy5LUEhxAXkVxs2ZaeZB6C2UQtmfRaF4BZEDz
7ffS1vAtuRVFvOKhunBEKXxjPrCmWxPXeARd1WtS9Pvs6jWdAwstBMsE1SET
AyplasipEZlU3myicTZHI+UZpQHaCsdqCmtZWO5QIvSJiYYD2h5nd4EFRjoh
KxgAQh8kOlpiy6ZxSgMV8gEXZmVwbZBLzg59FaVC6ZyGlU7vBdcybVwIZglL
UTFCdcjR5IyrNdjtUVoXqXe7hrWgMoFgkV0rEgxdK7UWTF8NmU7NBAN/Le+o
RAMwyEl8Z9DIMKk9fUfyyHP2yE/QIKehHBMqUm1bo3XDRfEAlAOh7ioJLvez
dD6Fii3wuaKY0eW7xekCYLamwimd1eyHzIRjKX96if0RBba6T6mFKdWcsm2h
BVVn5hPVu4Qo8ZxLAoyVA2v4dl4OwE5tPPepoLlWK9QcqwrErrFBbTaNqRIp
PbkVkKCubNJzbN2IjCqzUZHTm3R+7q57sFJ1qSdLF7HN5O+1kIn+6lFFMYIt
hc5V0kkXisKGK5OgZsgTTIc9P/uSsCVuMjffyXtDsx2lbEE1vT3/DU3hI9mu
XbL/PjWEoOGVS92VEIDkWK2F2ANJOUZj7Hs83QkjQcXOgwQtSrGulLmJTglY
GCozKeTvQRbMZ5OySIswn7rDVlJN426zGFKuO3SdgopssxNS082tN1FAatHj
1Wy+oPv73pg+fkTzxtQmUaoGSCmiNDNU60X+VMvoJaf7Fakle6nNgV+VWlaA
p+LXsNOuQcvGHVSW1LcyMR8xdD+12WZefcF47eA22CmvSeEFkHymhzCGRpcm
ucB2bx+DZWS/ccs/0avwUIlyiHCAm85nsf7+/dwK+rO6JuX0/vkPx43Ri/hy
0GSte6QiTwxM4fStNyUUsE7NsEZESpQoX3Mst6rpDrGPSO3dIsDuE+hMUD7E
c628lqiyBlmU6KOVuYMPu67Rib5DaqKVm0Hm+fff3jd6T8u1Sf0FEELRoCbA
uL//hgGGdhrR7bl1kfMsSETDhMwGfSEOMIykCWEoY343YHjLzScqRjsR/bAn
gaMUox9kaKfRKEEVJF1FFhMvVTcXSmmZKZMhjKJBbcMQy4H2IsL+LJvWbfte
G8+98O2RemdNLdS7SxjPYrhzV62lxsktRh2Qa5y8BMUtHcSmIkA5/2Pfnuns
UnP6ytJLnavwI6cyyVtSpDFc/GQYDa5/AQyvRsdFqH2SR9QSjpks6ZqrLska
fhSMFmjCC3rrxXmaYLOr2Vef/Q3vU3sotwwAAA==

-->

</rfc>
