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 2 October 2023.¶

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

Figure Figure 1 focuses on the management part of the SCHC architecture.¶

     .......................................................
     .   .................................                 .
     v   ^                               v                 ^
   (--------)     +----------+        +-------+    +-------+-------+
   ( Set of )<--->|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.¶

2. Attack scenario

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.¶

3. YANG Access Control

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

4. 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 the access rights. If these leaves are not presents, 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 IPv6 over Low Power Wide-Area Networks (lpwan) working group";
  contact
    "WG Web:   <https://datatracker.ietf.org/wg/lpwan/about/>
     WG List:  <mailto:lp-wan@ietf.org>
     Editor:   Juan-Carlos Zuniga
       <mailto:juancarlos.zuniga@sigfox.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 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;
        }
  }


}

<CODE ENDS>

Appendix B. Security Considerations

TBD¶

Appendix C. IANA Considerations

TBD¶

Authors' Addresses