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

Versions: 00

T2TRG Research Group                                          J. Jimenez
Internet-Draft                                                  Ericsson
Intended status: Informational                            March 09, 2020
Expires: September 10, 2020


                     Using MUD on CoAP environments
                    draft-jimenez-t2trg-mud-coap-00

Abstract

   This document provides some guidelines on how to add Manufacturer
   Usage Descriptions (MUD) to CoAP environments.

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 September 10, 2020.

Copyright Notice

   Copyright (c) 2020 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.






Jimenez                Expires September 10, 2020               [Page 1]


Internet-Draft                MUD and CoAP                    March 2020


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  MUD Architecture  . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Problems  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  MUD architecture using CoAP . . . . . . . . . . . . . . . . .   4
     3.1.  Problems  . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Finding a policy: MUD URL advertisement . . . . . . . . . . .   5
     4.1.  Dynamic Host Configuration Protocol (DHCP)  . . . . . . .   5
     4.2.  Neighbor Discovery Protocol (NDP) . . . . . . . . . . . .   6
       4.2.1.  NDP on 6LoWPANs . . . . . . . . . . . . . . . . . . .   6
     4.3.  Stateless autoconfiguration (SLAAC) . . . . . . . . . . .   6
   5.  CoAP Operations . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Discovery . . . . . . . . . . . . . . . . . . . . . . . .   6
       5.1.1.  Resource Directory  . . . . . . . . . . . . . . . . .   6
       5.1.2.  Multicast . . . . . . . . . . . . . . . . . . . . . .   7
       5.1.3.  Direct MUD discovery  . . . . . . . . . . . . . . . .   8
   6.  MUD File  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Serialization . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Manufacturer Usage Descriptions (MUDs) have been specified in
   [RFC8520].  As the RFC states, the goal of MUD is to provide a means
   for end devices to signal to the network what sort of access and
   network functionality they require to properly function.

   Schemes that rely on connectivity to bootstrap the network might be
   flaky if that connectivity is not present, potentially preventing the
   device from working correctly in the absence of Internet
   connectivity.  Moreover, even in environments that do provide
   connectivity it is unclear how continued operation can occur when the
   manufacturer's server is no longer available.

   While [RFC8520] contemplates the use of CoAP [RFC7252] in the form of
   CoAP URLs, it does not explain how MUDs can be used in a CoAP
   network.  Moreover, in CoAP the MUD file can be hosted on the CoAP
   endpoint itself, instead of hosting it on a dedicated MUD File
   Server.




Jimenez                Expires September 10, 2020               [Page 2]


Internet-Draft                MUD and CoAP                    March 2020


1.1.  Requirements Language

   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.  MUD Architecture

   MUDs are defined in [RFC8520] and are composed of:

   o  A URL that can be used to locate a description;

   o  the description itself, including how it is interpreted; and

   o  a means for local network management systems to retrieve the
      description;

   o  which is retrieved from a MUD File Server.

   In a MUD scenario, the end device is a "Thing" that exposes a "MUD
   URL" to the network.  Routers or Switches in the path that speak MUD
   can forward the URL to "MUD Managers" that query a "MUD file server"
   and retrieve the "MUD File" from it.  After processing, the "MUD
   Manager" applies an access policy to the IoT Thing.

  .......................................                      +-------+
  .                      ____________   .                      |  MUD  |
  .                     +            +  .          +-----------+-+File |
  .                     |    MUD     +-->get URL+->+    MUD      +-----+
  .                     |  Manager   |  .(https)   | File Server |
  .  End system network +____________+<+MUD file<-<+-------------+
  .                             .       .
  .                             .       .
  . _______                 _________   .
  .+       + (DHCP et al.) + router  +  .
  .| Thing +---->MUD URL+->+   or    |  .
  .+_______+               | switch  |  .
  .                        +_________+  .
  .......................................


                    Figure 1: Current MUD Architecture

   The general operation consists on a Thing emitting the MUD as a URL
   using DHCP, LLDP or through 802.1X, then a Switch or Router will send




Jimenez                Expires September 10, 2020               [Page 3]


Internet-Draft                MUD and CoAP                    March 2020


   the URI to some IoT Controlling Entity.  That Entity will fetch the
   MUD file from a Server on the Internet over HTTP.

   MUDs can be used to mitigate DDOS attacks to and from devices, for
   example by prohibiting unauthorized traffic to and from IoT devices.
   MUD also prevents devices from becoming the attacker, as that would
   require the device to send traffic to an unauthorized destination.
   Overall MUDs can be used to automatically permit the device to send
   and receive only the traffic it requires to perform its intended
   function.

   This is indeed an important subject as trustworthy IoT operations is
   a recurring topic in the IETF [RFC8576].

2.1.  Problems

   The biggest issue with this architecture is that if the MUD File
   server is not available at a given time, no Thing can actually join
   the network.  Relying on a single server is generally not a good
   idea.  The DNS name may point to a load balancer group, but then that
   would require added infrastructure and complexity.

   Another potential issue is that MUD files seem to be oriented to
   classes of devices and not specific device instances.  It could be
   that during bootstrapping or provisioning different devices of the
   same class have different properties and thus different MUD files,
   more granularity would be preferable.  This could be achieved by
   creating per-device MUD files on the server, but that mechanism does
   not seem to have been currently specified.

   This brings us to the third problem, which is that the MUD file is
   somewhat static on a web server and out of the usual interaction
   patterns towards a device.  In CoAP properties that are intrinsic to
   a device (e.g. sensing information) or configuration information
   (e.g. lwm2m objects used for management) are hosted by the device
   too, even if they could be replicated by a cloud server.

3.  MUD architecture using CoAP

   [RFC8520] allows a Thing to use the CoAP protocol scheme on the MUD
   URL.  In this document we modify slightly the architecture.  The
   components are:

   o  A URL using the "coaps://" scheme that can be used to locate a
      description;

   o  the description itself, including how it is interpreted, which is
      now hosted and linked from "/.well-known/core" and



Jimenez                Expires September 10, 2020               [Page 4]


Internet-Draft                MUD and CoAP                    March 2020


   o  a means for local network management systems to retrieve the MUD
      description

   o  which is hosted by the Thing itself acting as CoAP MUD File
      Server.

            ...................................................
            .                                  ____________   .
            .                                 +            +  .
            .             +------------------ |    MUD     |  .
            .   get URL   |                   |  Manager   |  .
            .   (coaps)   |                   +____________+  .
            .  MUD file   |                         .         .
            .             |                         .         .
            .             |     End system network  .         .
            .             |                         .         .
            .           __v____                 _________     .
            .          +       + (DHCP et al.) + router  +    .
            .     +--- | Thing +---->MUD URL+->+   or    |    .
            .     |MUD +_______+               | switch  |    .
            .     |File  |                     +_________+    .
            .     +------+                                    .
            ...................................................

                  Figure 2: Self-hosted MUD Architecture

3.1.  Problems

   This design has some problems of its own.  The main being that, if
   DHCP is restricted in the network, the device may not be able to
   advertise a functional MUD URL ([RFC8520] Section 1.9).

4.  Finding a policy: MUD URL advertisement

   A CoAP endpoint will emit a URL that uses the CoAP scheme [RFC7252].
   This URL serves both to classify the device type and to provide a
   means to locate a policy file, as specified on [RFC8520].

4.1.  Dynamic Host Configuration Protocol (DHCP)

   [RFC8520] specifies a new MUD URL DHCP Option that carries the MUD
   URL to the DHCP Server.  The functioning is the same as specified on
   [RFC8520].

   If the DHCP Server cannot provide a valid IPv4 or IPv6 address, the
   device may use a temporary IPv6 link-local address as base URI (e.g.
   "coaps://[FE80::AB8]/mud/light-class").  As link local is not a




Jimenez                Expires September 10, 2020               [Page 5]


Internet-Draft                MUD and CoAP                    March 2020


   globally addressable address, the MUD Manager will only be able to
   reach the device if it is in the same network as the device.

   TBD : IPv4, coap://, ...

4.2.  Neighbor Discovery Protocol (NDP)

   IPv6 hosts do not require DHCP to get access to the default gateway.
   [RFC4861] can also be used to advertise the MUD URL.

   TBD : Figure out how these work - Neighbor Solicitation (type 135) -
   Neighbor Advertisement (type 136) - Redirect (type 137)

4.2.1.  NDP on 6LoWPANs

   LoWPANs are characterized as lossy, low-power, low-bit-rate, short-
   range; with many nodes saving energy with long sleep periods.  For
   that reason vanilla NDP [RFC4861] might not be the most desiderable
   solution in such networks and optimizations like the ones provided by
   [RFC6775] are required.

   TBD : Figure out how these work

4.3.  Stateless autoconfiguration (SLAAC)

   [RFC4862] specifies how to create and auto configure link-local
   addresses during system startup.

   TBD : Figure out how these work

5.  CoAP Operations

   Things can expose MUDs as any other resource.  MUD Managers can send
   a GET requests to a CoAP server for "/.well-known/core" and get in
   return a list of hypermedia links to other resources hosted in that
   server.  Among those, it will get the path to the MUD file, for
   example "/mud" and Resource Types like "rt=mud".

5.1.  Discovery

5.1.1.  Resource Directory

   By using [I-D.ietf-core-resource-directory], devices can register a
   MUD file on the Resource Directory and use it as a MUD repository
   too.  Making it discoverable with the usual RD Lookup steps.

   Lookup will use the resource type "rt=mud", the example in Link-
   Format [RFC6690] is:



Jimenez                Expires September 10, 2020               [Page 6]


Internet-Draft                MUD and CoAP                    March 2020


   REQ: GET coap://rd.company.com/rd-lookup/res?rt=mud

   RES: 2.05 Content

        <coap://[2001:db8:3::101]/mud/box>;rt=mud;
          anchor="coap://[2001:db8:3::101]"
        <coap://[2001:db8:3::102]/mud/switch>;rt=mud;
          anchor="coap://[2001:db8:3::102]",
        <coap://[2001:db8:3::102]/mud/lock>;rt=mud;
          anchor="coap://[2001:db8:3::102]",
        <coap://[2001:db8:3::104]/mud/light>;rt=mud;
          anchor="coap://[2001:db8:3::104]"

   The same example in CoRAL ([I-D.ietf-core-coral],
   [I-D.hartke-t2trg-coral-reef]) is:

   REQ: GET coap://rd.company.com/rd-lookup/res?rt=mud
        Accept: TBD123456 (application/coral+cbor@identity)

   RES: 2.05 Content
        Content-Format: TBD123456 (application/coral+cbor@identity)

        rd-item <coap://[2001:db8:3::101]/mud/box> { rt "mud" }
        rd-item <coap://[2001:db8:3::102]/mud/switch> { rt "mud" }
        rd-item <coap://[2001:db8:3::102]/mud/lock> { rt "mud" }
        rd-item <coap://[2001:db8:3::103]/mud/light> { rt "mud" }

5.1.2.  Multicast

   [RFC7252] registers one IPv4 and one IPv6 address each for the
   purpose of CoAP multicast.  All CoAP Nodes can be addressed at
   "224.0.1.187" and at "FF0X::FD".  Multicast could also be used to
   discover all Manufacturer descriptions in a subnet.

   The example in Link-Format [RFC6690] is:

   GET coap://[FF0X::FE]/.well-known/core?rt=mud

   The same example in CoRAL ([I-D.ietf-core-coral],
   [I-D.hartke-t2trg-coral-reef]) is:

   REQ: GET coap://[FF0X::FE]/.well-known/core?rt=mud
        Accept: TBD123456 (application/coral+cbor@identity)








Jimenez                Expires September 10, 2020               [Page 7]


Internet-Draft                MUD and CoAP                    March 2020


5.1.3.  Direct MUD discovery

   Using [RFC6690] using CoRE Link Format, a CoAP endpoint could attempt
   to configure itself based on another Thing's MUD.  For that reason it
   might fetch directly the MUD file from the device.  It would start by
   finding if the endpoint has a MUD.  The example in Link-Format
   [RFC6690] is:

   REQ: GET coap://[2001:db8:3::123]:5683/.well-known/core?rt=mud

   RES: 2.05 Content

        </mud/light>;rt=mud

   In CoRAL ([I-D.ietf-core-coral], [I-D.hartke-t2trg-coral-reef]):

   REQ: GET coap://[2001:db8:3::123]:5683/.well-known/core?rt=mud
        Accept: TBD123456 (application/coral+cbor@identity)

   RES: 2.05 Content
        Content-Format: TBD123456 (application/coral+cbor@identity)

        rd-item </mud/light> { rt "mud" }

   Once the client knows that there is a MUD file under "/mud/lightmud",
   it can decide to follow the presented links and query it.

   REQ: GET coap://[2001:db8:3::123]:5683/mud/light
   RES: 2.05 Content

        [{MUD Payload in SENML}]

   In CoRAL ([I-D.ietf-core-coral], [I-D.hartke-t2trg-coral-reef]):

   REQ: GET coap://[2001:db8:3::123]:5683/mud/light

   RES: 2.05 Content

        [{MUD Payload in SENML}]

   The device may also observe the MUD resource using [RFC7641],
   directly subscribing to future network configuration changes.

6.  MUD File

   TBD.  Behaviors that are specific of CoAP should be here.





Jimenez                Expires September 10, 2020               [Page 8]


Internet-Draft                MUD and CoAP                    March 2020


6.1.  Serialization

   TBD.  Write about SenML/CBOR MUDs.

7.  Security Considerations

   TBD.

   Things will expose a MUD file that has to be be signed both by the
   MUD author and by the device operator.  Security Considerations
   present on Section 4.1 of [RFC8576].

   We might want to use BRSKI or another similar mechanism.

   Optionally the device could advertise localhost on the URL with the
   path to the MUD.  When the network has the IP it'd append the path to
   it in order to fetch the MUD.

   If the host part is always dynamically computed how are bootstrap /
   attachment schemes that depend on certs (EAP) work?

8.  IANA Considerations

   TBD: rt=mud should be registered.

9.  References

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

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              DOI 10.17487/RFC4861, September 2007,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.








Jimenez                Expires September 10, 2020               [Page 9]


Internet-Draft                MUD and CoAP                    March 2020


   [RFC6775]  Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
              Bormann, "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Networks (6LoWPANs)",
              RFC 6775, DOI 10.17487/RFC6775, November 2012,
              <https://www.rfc-editor.org/info/rfc6775>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

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

9.2.  Informative References

   [I-D.hartke-t2trg-coral-reef]
              Hartke, K., "Resource Discovery in Constrained RESTful
              Environments (CoRE) using the Constrained RESTful
              Application Language (CoRAL)", draft-hartke-t2trg-coral-
              reef-03 (work in progress), November 2019.

   [I-D.ietf-core-coral]
              Hartke, K., "The Constrained RESTful Application Language
              (CoRAL)", draft-ietf-core-coral-02 (work in progress),
              January 2020.

   [I-D.ietf-core-resource-directory]
              Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
              Amsuess, "CoRE Resource Directory", draft-ietf-core-
              resource-directory-23 (work in progress), July 2019.

   [RFC6690]  Shelby, Z., "Constrained RESTful Environments (CoRE) Link
              Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
              <https://www.rfc-editor.org/info/rfc6690>.

   [RFC7641]  Hartke, K., "Observing Resources in the Constrained
              Application Protocol (CoAP)", RFC 7641,
              DOI 10.17487/RFC7641, September 2015,
              <https://www.rfc-editor.org/info/rfc7641>.





Jimenez                Expires September 10, 2020              [Page 10]


Internet-Draft                MUD and CoAP                    March 2020


   [RFC8576]  Garcia-Morchon, O., Kumar, S., and M. Sethi, "Internet of
              Things (IoT) Security: State of the Art and Challenges",
              RFC 8576, DOI 10.17487/RFC8576, April 2019,
              <https://www.rfc-editor.org/info/rfc8576>.

Acknowledgments

   Thanks to Thomas Fossati, Klaus Hartke, Carsten Bormann and Michael
   Richardson for discussions on the problem space and reviews.

Author's Address

   Jaime Jimenez
   Ericsson

   Phone: +358-442-992-827
   Email: jaime@iki.fi


































Jimenez                Expires September 10, 2020              [Page 11]


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