SCHC Rule Access ControlAcklio1137A avenue des Champs Blancs35510 Cesson-Sevigne CedexFranceana@ackl.ioInstitut MINES TELECOM; IMT Atlantique2 rue de la ChataigneraieCS 1760735576 Cesson-Sevigne CedexFranceLaurent.Toutain@imt-atlantique.frInstitut MINES TELECOM; IMT Atlantique2 rue de la ChataigneraieCS 1760735576 Cesson-Sevigne CedexFranceivan-marino.martinez-bolivar@imt-atlantique.frlpwan Working GroupThe 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.Figure focuses on the management part of the SCHC architecture.|coreconf |<=======|Access |<===| other end |<===
( Rules ) |request | |Control| | authentication|
(--------) |processing| +-------+ +---------------+
+----------+
]]>When a management request arrives on a SCHC instance, the identity of the requester must be
checked:this can be implicit, for instance a LPWAN device receives it from the SCHC core instance. Authentication
is done at Layer 2.this can be a L2 address. In a LoRaWAN network, the DevEUI allows the SCHC core instance to identify the device.IP addresses may also be used as well as cryptographic keys.The identification of the requester allows to retrieve the associated Set of Rules. This rules are enriched with
access control information that will be defined in this document. If the Set of Rules do not contains any access control information, the management is not allowed to modify the Rules content.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.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.YANG language allows to specify read only or read write nodes. NACM extends this by allowing users or group od users to perform specific actions.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.The SCHC access control augments the YANG module defined in to allow a remote entity to manipulate the rules. Several levels are defined.in the set of rules, it authorizes or not a new rule to be added .in a compression rule, it allows to add or remove field descriptions.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.in a fragmentation rule, it allows to modify some parameters.The YANG DM proposed in extends the SCHC YANG Data Model introduced in . It adds read-only leaves containing the access rights. If these leaves are not presents, the information cannot be modified.This leaf controls modifications applied to a set of rules. They are specified with the rule-access-right enumeration:no-change (0): rules cannot be modified in the Set of Rules. This is the equivalent of having no access control elements in the set of rules.modify-existing-element (1): an existing rule may be modified.add-remove-element (2): a rule can be added or deleted from the Set of Rules or an existing rule can be modified.This leaf allows to modify a compression element. To be active, leaf ac-modify-set-of-rules MUST be set to modify-existing-element or add-remove-element. This leaf uses the same enumeration as add-remove-element:no-change (0): The rule cannot be modified.modify-existing-element (1): an existing Field Description may be modified.add-remove-element (2): a Field Description can be added or deleted from the Rule or an existing rule can be modified.This leaf allows to modify a Field Description in a compression rule. To be active, leaves ac-modify-set-of-rules and ac-modify-compression-rule MUST be set to modify-existing-element or add-remove-element and ac-modifiy-compression-rule and leafStatic Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)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.Network Configuration Access Control ModelThe 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.This document obsoletes RFC 6536.Data Model for Static Context Header Compression (SCHC)AcklioInstitut MINES TELECOM; IMT AtlantiqueThis 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. file "ietf-schc-access-control@2023-02-14.yang"
module ietf-schc-access-control {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-schc-access-control";
prefix schc-ac;
import ietf-schc {
prefix schc;
}
organization
"IETF IPv6 over Low Power Wide-Area Networks (lpwan) working group";
contact
"WG Web:
WG List:
Editor: Juan-Carlos Zuniga
";
description
"
Copyright (c) 2021 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject to
the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX
(https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself
for full legal notices.
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
'MAY', and 'OPTIONAL' in this document are to be interpreted as
described in BCP 14 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.
*************************************************************************
This module extends the ietf-schc module to include the compound-ack
behavior for Ack On Error as defined in RFC YYYY.
It introduces a new leaf for Ack on Error defining the format of the
SCHC Ack and add the possibility to send several bitmaps in a single
answer.";
revision 2023-02-14 {
description
"Initial version for RFC YYYY ";
reference
"RFC YYYY: Compound Ack";
}
typedef rule-access-right {
type enumeration {
enum no-changes {
value 0;
description
"No change are allowed.";
}
enum modify-existing-element {
value 1;
description
"can modify content inside an element.";
}
enum add-remove-element {
value 2;
description
"Allows to add or remove or modify an element.";
}
}
}
typedef field-access-right {
type enumeration {
enum no-change {
value 0;
description
"Reserved slot number.";
}
enum change-tv {
value 1;
description
"Reserved slot number.";
}
enum change-mo-cda-tv {
value 2;
description
"Reserved slot number.";
}
}
}
augment "/schc:schc/schc:rule" {
leaf ac-modify-set-of-rules {
config false;
type rule-access-right;
}
}
augment "/schc:schc/schc:rule/schc:nature/schc:compression" {
leaf ac-modify-compression-rule {
config false;
type rule-access-right;
}
}
augment "/schc:schc/schc:rule/schc:nature/schc:compression/schc:entry" {
leaf ac-modify-field {
config false;
type field-access-right;
}
}
augment "/schc:schc/schc:rule/schc:nature/schc:fragmentation" {
leaf ac-modify-timers {
config false;
type boolean;
}
}
}
]]>TBDTBD