SCHC Rule Access Control

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 26 January 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

SCHC is a compression and fragmentation mechanism defined in [RFC8724] while [RFC9363] provides a YANG Data Model for formal representation of SCHC Rules used either for compression/decompression (C/D) or fragmentation/reassembly (F/R). [I-D.ietf-schc-architecture] illustrates the use of several protocols for rule management using the YANG Data Model, such as CORECONF [I-D.ietf-core-comi], NETCONF[RFC6241], RESTCONF [RFC8040]. The inappropriate use of any of these protocols leads to some possible attacks. The goal of this document is to define a threat model, summarize some possible attacks, and define augmentation to the existing Data Model in order to restrict the changes in the rules and, therefore, the impact of possible attacks.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

It is expected that the reader will be familiar with the terms and concepts associated with the SCHC framework [RFC8724], [I-D.ietf-schc-architecture], and managmente request processing [I-D.ietf-core-comi], NETCONF[RFC6241], RESTCONF [RFC8040].¶

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¶

4. SCHC Management Architecture

Figure Figure 1 presents the management part of the SCHC architecture.¶

  ........................................
  .  ..........................          .
  v  ^    create              v          ^
(-------)  read  +====+    +==+==+   +===+===+   +=========+
(Context)<------>| RM |<-->|Mgmt.|<==|Access |<==|Other end|<===
(-------) update +====+    |req. |   |Control|   |auth.    | Management
          delete           |proc.|   +=======+   +=========+ Request
                           +=====+                           NETCONF,
                                                             RESTCONF
                                                          or CORECONF

When a management request arrives on a SCHC endpoint, several processes should be passed before effectively creating or updating a Rule:¶

1. Other end authentication: the identity of the requester must be verified:¶

   • This can be implicit, for example, an LPWAN device that receives it from the SCHC core. Hence, authentication is done at Layer 2.¶
   • This can be an L2 address. In a LoRaWAN network, for example, the DevEUI allows the SCHC core to identify the device.¶
   • IP addresses may also be used, as well as cryptographic keys.¶

2. Access control: Once authenticated, the associated Set of Rules of the instance is retrieved.¶

   • These rules are enriched with access control information that will be defined in this document.¶
   • If the Set of Rules does not contain any access control information, the end-point is not allowed to modify the Rules' content.¶
3. Management request processing: The NETCONF, RESTCONF or CORECONF request is processed and passed to the end-point Rule Manager.¶
4. The Rule Manager (RM) applies the changes (create, read, update, or delete) to the Rule database.¶

5. Threat Model

The RM is in charge of applying changes to the context when a management request arrives at a SCHC end-point. It is assumed that these changes should only be effectively applied when it is sure that all end-points of an instance have made the change. This means that in all cases, a peer of peers in an instance always shares the same Set of Rules.¶

The selection of a rule to be applied in an accurate endpoint when a packet arrives is made by selecting the rule offering the best-performance SCHC packet after compression.¶

The attack scenarios considered below are limited to the rule management layer and only involve that a single endpoint in a given instance has been compromised. This means that the authentication is bypassed. Therefore, the compromised endpoint is able to effectively deliver management requests using NETCONF, RESTCONF, or CORECONF to the other endpoint.¶

6. 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. Figure 2 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.¶

 +-----------------+------------------------------------------------------+
 |                 |                      CDA                             |
 |  TV   /  MO     +--------+---------------+-----+---------+------+------+
 |                 |not-sent| value |mapping| LSB |compute-*|DevIID|AppIID|
 |                 |        | -sent | -sent |     |         |      |      |
 +-----------------+--------+-------+-------+-----+---------+------+------+
 |  set  /  Equal  |  ok    |absurd |   x   |  x  | absurd  |absurd|absurd|
 +-----------------+--------+-------+-------+-----+---------+------+------+
 | not set / Equal |   x    |   x   |   x   |  x  | absurd  |absurd|absurd|
 +-----------------+--------+-------+-------+-----+---------+------+------+
 |  set  / Ignore  | ok (D) | absurd|    x  |  x  |   ok    |  ok  |  ok  |
 +-----------------+--------+-------+-------+-----+---------+------+------+
 |not set / Ignore |   x    |  ok   |    x  |  x  |   ok    |  ok  |  ok  |
 +-----------------+--------+-------+-------+-----+---------+------+------+
 |  set   /   MSB  | absurd |absurd |    x  |  ok |  absurd |absurd|absurd|
 +-----------------+--------+-------+-------+-----+---------+------+------+
 | not set /  MSB  | absurd | absurd|    x  | ok  |  absurd |absurd|absurd|
 +-----------------+--------+-------+-------+-----+---------+------+------+
 |  set   /  Match |   x    | absurd|   ok  |  x  |  absurd |absurd|absurd|
 |         -mapping|        |       |       |     |         |      |      |
 +-----------------+--------+-------+-------+-----+---------+------+------+
 |not set /  Match |   x    |   x   | absurd|  x  |  absurd |absurd|absurd|
 |         -mapping|        |       |       |     |         |      |      |
 +-----------------+--------+-------+-------+-----+---------+------+------+

7. Attack Scenarios

## Scenario 1: Compromised Device¶

A Device RM, under the control of an attacker, sends some management messages to modify the SCHC rules in the core in order to direct the traffic to another application. The impact of this attack is different depending on the original rule:¶

1. Rules containing exclusively the pair MO -- CDA : (ignore -- not-sent) or rules such as no-compress or no-fragmentation:¶

   • There is no risk of information lost.¶
   • There is a risk of a DoS-type attack as it can flood empty packets that pass at the core level.¶

For example ... TBD¶

The attack is limited to a single end-point (the device) since it does not have the right to change core-level rules.¶

1. Management messages aiming at changing rules where the length of the residue changes:¶

   • There can be a risk of desynchronizing rules between the core and the compromised device.¶
   • The attack is limited to a single end-point (the device) since it does not have the right to change core-level rules.¶

As SCHC rules are defined for specific traffic. An example of this can be an attacker changing an element of the rule (the dev UDP port number, for instance), and therefore no rule matches the traffic. Therefore, the core may be saturated by no-compressed messages.¶

8. YANG Access Control

YANG language allows to specify read-only or read write nodes. NACM [RFC8341] 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 [RFC9363] 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.¶

9. YANG Data Model

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

Appendix A. YANG Data Model

<CODE BEGINS> 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 Static Context Header Compression (schc) working group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/schc/about/>
     WG List:  <mailto:schc@ietf.org>
     Editor:   Ana Minaburo
       <mailto:anaminaburo@gmail.com>";
  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 rule access
     control behaviour in RFC YYYY.";

  revision 2023-02-14 {
    description
      "Initial version for RFC YYYY ";
    reference
      "RFC YYYY: SCHC AC";
  }

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


}

<CODE ENDS>

Appendix B. Security Considerations

TBD¶

Appendix C. IANA Considerations

TBD¶

Authors' Addresses