]> Consultant

Rue de Rennes 35510 Cesson-Sevigne Cedex France anaminaburo@gmail.com

Institut MINES TELECOM; IMT Atlantique

2 rue de la Chataigneraie CS 17607 35576 Cesson-Sevigne Cedex France Laurent.Toutain@imt-atlantique.fr

Nokia Bell Labs

12 Rue Jean Bart 91300 Massy France ivan.martinez_bolivar@nokia-bell-labs.com

Internet SCHC Working Group Internet-Draft The framework for SCHC defines an abstract view of the rules, formalized through a YANG Data Model. In its original description, rules are static and shared by two endpoints. This document defines defines augmentation to the existing Data Model in order to restrict the changes in the rule and, therefore, the impact of possible attacks.

Introduction SCHC is a compression and fragmentation mechanism defined in while provides a YANG Data Model for formal representation of SCHC Rules used either for compression/decompression (C/D) or fragmentation/reassembly (F/R). The inappropriate changes to SCHC Rules leads to some possible attacks. The goal of this document is to define a augmentation to the existing Data Model in order to restrict the changes in the rules and, therefore, the impact of possible attacks.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Terminology It is expected that the reader will be familiar with the terms and concepts associated with the SCHC framework , , and managmente request processing , NETCONF, RESTCONF . ToDo * Access Control. * Management request processing: The NETCONF, RESTCONF or CORECONF request is processed and passed to the end-point Rule Manager. * Rule Manager (RM). * Context. SCHC Rules

SCHC TV/MO/CDA possible combinations SCHC compression behavior uses the TV, MO, and CDA to generate the correct residue. But not all the combinations of this fields descriptors are possible, and then an attack can be detected or avoided. shows all the combinations and those that are enabled. SCHC defines two TV values: set and not set. SCHC MO can be Equal, Ignore, MSB, or Match-mapping. And SCHC CDA can be not-sent, value-sent, mapping-sent, LSB, compute-*, DevIID, or AppIID.

YANG Access Control YANG language allows to specify read-only or read write nodes. NACM extends this by allowing users or groups of users to perform specific actions. This granularity does not fit this 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 FID containing Uri-path may have its target value modified, as in the same rule, the entry regarding the application 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 adding or removing field descriptions. in a compression rule, it allows modifying some elements of the rule, such as the TV, MO, or/and CDA, and associated values. in a fragmentation rule, it allows modifying some parameters.

YANG Data Model The YANG DM proposed in extends the SCHC YANG Data Model introduced in . It adds read-only leaves containing access rights. If these leaves are not present, the information cannot be modified.

leaf ac-modify-set-of-rules 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.

leaf ac-modify-compression-rule 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.

leaf ac-modify-field 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-modify-compression-rule and leaf.

CoAP base header Access Control. CoAP protocol uses a request/reply model with compact messages. The format of these messages starts with a fixed format of 4-byte length, followed by a variable Token format with a length between 0 and 8 bytes. While applying SCHC header compression , the based header is only readable and MUST NOT be modified. shows the access-control for the FID and TV in a Rules.

CoAP Options Access Control. The CoAP options are used by both request and responses messages. Some of them are defined as repeatable which implies that it MAY be included one or more times in a message. In this case, a SCHC Rule MAY be able to modify the FID and the TV in order to include the repetition. The only FID's that have access to be modifiable are those that have been defined as repeatable. The give the control access for all the CoAP Options defined in ; ; ; ; ; and .

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document defines the Static Context Header Compression and fragmentation (SCHC) framework, which provides both a header compression mechanism and an optional fragmentation mechanism. SCHC has been designed with Low-Power Wide Area Networks (LPWANs) in mind. SCHC compression is based on a common static context stored both in the LPWAN device and in the network infrastructure side. This document defines a generic header compression mechanism and its application to compress IPv6/UDP headers. This document also specifies an optional fragmentation and reassembly mechanism. It can be used to support the IPv6 MTU requirement over the LPWAN technologies. Fragmentation is needed for IPv6 datagrams that, after SCHC compression or when such compression was not possible, still exceed the Layer 2 maximum payload size. The SCHC header compression and fragmentation mechanisms are independent of the specific LPWAN technology over which they are used. This document defines generic functionalities and offers flexibility with regard to parameter settings and mechanism choices. This document standardizes the exchange over the LPWAN between two SCHC entities. Settings and choices specific to a technology or a product are expected to be grouped into profiles, which are specified in other documents. Data models for the context and profiles are out of scope. 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. This document describes a YANG data model for the Static Context Header Compression (SCHC) 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 the parameters of some Rules. 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. This document obsoletes RFC 6536. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. The presence of Constrained Application Protocol (CoAP) proxies may lead to infinite forwarding loops, which is undesirable. To prevent and detect such loops, this document specifies the Hop-Limit CoAP option. This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2. These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission. The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and amplification mitigation (where the use of the Echo option is now recommended). Trilliant Networks Inc. consultant Acklio YumaWorks Universität Bremen TZI This document describes a network management interface for constrained devices and networks, called CoAP Management Interface (CORECONF). The Constrained Application Protocol (CoAP) is used to access datastore and data node resources specified in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and converts YANG identifier strings to numeric identifiers for payload size reduction. CORECONF extends the set of YANG based protocols, NETCONF and RESTCONF, with the capability to manage constrained devices and networks. IMT Atlantique Consultant This document defines the SCHC architecture.

YANG Data Model

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; } } } ]]>

Security Considerations TBD

IANA Considerations TBD