Skip to main content

SCHC Rule Access Control
draft-toutain-schc-access-control-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Authors Ana Minaburo , Laurent Toutain , Ivan Martinez
Last updated 2023-03-31
Replaced by draft-ietf-schc-access-control
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-toutain-schc-access-control-00
lpwan Working Group                                          A. Minaburo
Internet-Draft                                                    Acklio
Intended status: Standards Track                              L. Toutain
Expires: 2 October 2023                                      I. Martinez
                                  Institut MINES TELECOM; IMT Atlantique
                                                           31 March 2023

                        SCHC Rule Access Control
                  draft-toutain-schc-access-control-00

Abstract

   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.

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

Minaburo, et al.         Expires 2 October 2023                 [Page 1]
Internet-Draft                   SCHC AC                      March 2023

   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Attack scenario . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  YANG Access Control . . . . . . . . . . . . . . . . . . . . .   3
   4.  YANG Data Model . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  leaf ac-modify-set-of-rules . . . . . . . . . . . . . . .   4
     4.2.  leaf ac-modify-compression-rule . . . . . . . . . . . . .   4
     4.3.  leaf ac-modify-field  . . . . . . . . . . . . . . . . . .   4
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Appendix A.  YANG Data Model  . . . . . . . . . . . . . . . . . .   5
   Appendix B.  Security Considerations  . . . . . . . . . . . . . .   8
   Appendix C.  IANA Considerations  . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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|        +-------+    +---------------+
                  +----------+

            Figure 1: Overview of management architecture.

   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.

Minaburo, et al.         Expires 2 October 2023                 [Page 2]
Internet-Draft                   SCHC AC                      March 2023

   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.

Minaburo, et al.         Expires 2 October 2023                 [Page 3]
Internet-Draft                   SCHC AC                      March 2023

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.

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

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

4.3.  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-modifiy-compression-rule and leaf

5.  Normative References

Minaburo, et al.         Expires 2 October 2023                 [Page 4]
Internet-Draft                   SCHC AC                      March 2023

   [RFC8341]  Bierman, A. and M. Bjorklund, "Network Configuration
              Access Control Model", STD 91, RFC 8341,
              DOI 10.17487/RFC8341, March 2018,
              <https://www.rfc-editor.org/info/rfc8341>.

   [RFC8824]  Minaburo, A., Toutain, L., and R. Andreasen, "Static
              Context Header Compression (SCHC) for the Constrained
              Application Protocol (CoAP)", RFC 8824,
              DOI 10.17487/RFC8824, June 2021,
              <https://www.rfc-editor.org/info/rfc8824>.

   [RFC9363]  Minaburo, A. and L. Toutain, "A YANG Data Model for Static
              Context Header Compression (SCHC)", RFC 9363,
              DOI 10.17487/RFC9363, March 2023,
              <https://www.rfc-editor.org/info/rfc9363>.

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

Minaburo, et al.         Expires 2 October 2023                 [Page 5]
Internet-Draft                   SCHC AC                      March 2023

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

Minaburo, et al.         Expires 2 October 2023                 [Page 6]
Internet-Draft                   SCHC AC                      March 2023

           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>

Minaburo, et al.         Expires 2 October 2023                 [Page 7]
Internet-Draft                   SCHC AC                      March 2023

Appendix B.  Security Considerations

   TBD

Appendix C.  IANA Considerations

   TBD

Authors' Addresses

   Ana Minaburo
   Acklio
   1137A avenue des Champs Blancs
   35510 Cesson-Sevigne Cedex
   France
   Email: ana@ackl.io

   Laurent Toutain
   Institut MINES TELECOM; IMT Atlantique
   2 rue de la Chataigneraie
   CS 17607
   35576 Cesson-Sevigne Cedex
   France
   Email: Laurent.Toutain@imt-atlantique.fr

   Ivan Martinez
   Institut MINES TELECOM; IMT Atlantique
   2 rue de la Chataigneraie
   CS 17607
   35576 Cesson-Sevigne Cedex
   France
   Email: ivan-marino.martinez-bolivar@imt-atlantique.fr

Minaburo, et al.         Expires 2 October 2023                 [Page 8]