[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                            E. Lear
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                           July 01, 2019
Expires: January 2, 2020


              Controller Identification Extension for MUD
             draft-lear-opsawg-mud-controller-candidates-00

Abstract

   Manufacturer Usage Descriptions (MUD) are a means by which devices
   can establish expectations about how they are intended to behave, and
   how the network should treat them.  This extension provides a means
   for a MUD controller to identify itself through its own MUD file.

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 January 2, 2020.

Copyright Notice

   Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Lear                     Expires January 2, 2020                [Page 1]


Internet-Draft                   MUD QoS                       July 2019


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The ietf-mud-controller model extension . . . . . . . . . . .   3
     2.1.  The controller-candidate augmentation to the MUD YANG
           model . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Appendix A.  Changes from Earlier Versions  . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Manufacturer Usage Descriptions (MUD) [RFC8520] provides a means for
   devices to identify what they are and what sort of network access
   they need.  Two abstractions made available in that specification are
   "controller" and "my-controller".  As initially specified, these
   devices must be identfied by the network administrator.  To simplify
   the administrator's life, a means of identifying devices that are
   candidates to be a controller for another device is desirable.

   This memo specifies an extension that makes use of the MUD file of
   the controller itself.  It also sets the groundwork to create a
   RESTful interface for applications that are serving as controllers to
   make use of the same grouping.  However, that work is left either for
   a future version of this draft, or a future specification.

   For example, a light switch might identify as a candidate controller
   for luminaires.  A thermostat might identify as a controller for an
   air conditioner or heater.

   To address the case where "my-controller" is used, the manufacturer
   of a candidate controller must list the MUD URLs of devices that it
   knows it can serve.  For example, if thermostat manufacturer "Example
   Thermostat, Inc" knows that it can properly control a heater made by
   "Example Heating, Inc", and the heater has a mud url of
   "https://heating.example.com/mudurls/heater1000.json", the thermostat
   would list that or an expression matching that URL in its MUD URL.
   The heater's MUD file would be expected to contain a "my-controller"
   statement in order for this controller to be considered a candidate.

   To address the case where "controller" is used, then the class
   indicated by the controller must be named instead of a MUD URL.  In
   our previous example, let us assume that the heater1000.json file
   contains a "controller" statement with a class URI of
   "https://heating.example.com/theromstats".  In this case, the




Lear                     Expires January 2, 2020                [Page 2]


Internet-Draft                   MUD QoS                       July 2019


   controller would contain a statement that indicates it can be a
   controller for class "https://heating.example.com".

   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.

2.  The ietf-mud-controller model extension

   We now formally define this extension.  This is done in two parts.
   First, the extension name "controller-candidate" is listed in the
   "extensions" array of the MUD file.

   Second, the "mud" container is augmented to contain two optional
   lists, one that contains mud-urls that can be matched for "my-
   controller", and a second list that contains classes that can be
   matched against "controller".

   This is done as follows.

   module: ietf-mud-controller-candidate
     augment /mud:mud:
         +--rw controller-candidates
             +--rw urls*      inet:uri
             +--rw classes*   inet:uri


2.1.  The controller-candidate augmentation to the MUD YANG model

<CODE BEGINS>file "ietf-mud-controller-candidate@2019-06-20.yang"
module ietf-mud-controller-candidate {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-mud-controller-candidate";
  prefix mud-cc;

  import ietf-mud {
    prefix "mud";
  }

  import ietf-inet-types {
    prefix "inet";
  }

  organization
    "IETF OPSAWG (Ops Area) Working Group";
  contact



Lear                     Expires January 2, 2020                [Page 3]


Internet-Draft                   MUD QoS                       July 2019


    "WG Web: http://tools.ietf.org/wg/opsawg/
     WG List: opsawg@ietf.org
     Author: Eliot Lear
     lear@cisco.com
    ";
  description

    "This YANG module augments the ietf-mud model to provide for two
     optional lists to indicate that this device type may be used as
     a controller for other MUD-enabled devices.

     Copyright (c) 2019 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.
";

  revision 2019-06-20 {
    description
      "Initial proposed standard.";
    reference "RFC XXXX: QoS for MUD Specification";
  }

  grouping mud-controller-candidates {
    description
      "Controller candidate grouping";
    container controller-candidates {
      description
        "Lists of controller candidates.";
      leaf-list urls {
        type inet:uri;
        description
          "a list of mud urls this device is designed to control.



Lear                     Expires January 2, 2020                [Page 4]


Internet-Draft                   MUD QoS                       July 2019


           Each entry may end with a * to indicate a wildcard that
           matches zero or more of characters from that point.  A
           wildcard MUST NOT appear in the authority section of the
           URL.";
        }
        leaf-list classes {
          type inet:uri;
          description
            "A list of URIs that are used as classes in MUD files,
             indicating that this device can serve as a controller
             in those classes.";
        }
      }
    }

  augment "/mud:mud" {
    uses mud-controller-candidates;
    description
      "add controller candidate list";
  }
}
<CODE ENDS>


3.  Examples

   TBD

4.  Security Considerations

   All security considerations of [RFC8520] apply equally to this
   extension.  In addition, some care should be given to claims that a
   device is permitted to be a controller in any given circumstances.
   Complete automation requires far more context than is currently
   specified here.  Some form of confirmation or selection is required
   by an administrator.  This memo simply makes it easier for
   administrator to identify candidates for controller selection.

   IANA Considerations ===================

   The IANA is requested to add "controller-candidate" to the MUD
   extensions registry as follows:

     Extension Name: controller-candidate
     Standard reference: This document






Lear                     Expires January 2, 2020                [Page 5]


Internet-Draft                   MUD QoS                       July 2019


5.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6991]  Schoenwaelder, J., Ed., "Common YANG Data Types",
              RFC 6991, DOI 10.17487/RFC6991, July 2013,
              <https://www.rfc-editor.org/info/rfc6991>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8520]  Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
              Description Specification", RFC 8520,
              DOI 10.17487/RFC8520, March 2019,
              <https://www.rfc-editor.org/info/rfc8520>.

Appendix A.  Changes from Earlier Versions

   Draft -00:

   o  Initial revision

Author's Address

   Eliot Lear
   Cisco Systems
   Richtistrasse 7
   Wallisellen  CH-8304
   Switzerland

   Phone: +41 44 878 9200
   Email: lear@cisco.com















Lear                     Expires January 2, 2020                [Page 6]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/