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

Versions: 00

6lo Working Group                                          M. Richardson
Internet-Draft                                  Sandelman Software Works
Intended status: Standards Track                               J. Latour
Expires: August 17, 2019                                       CIRA Labs
                                                       February 13, 2019


        A standard process to quarantine and restore IoT Devices
                 draft-richardson-shg-un-quarantine-00

Abstract

   The Manufacturer Usage Description (MUD) is a tool to describe the
   limited access that a single function device such as an Internet of
   Things device might need.  The enforcement of the access control
   lists described protects the device from attacks from the Internet,
   and protects the Internets from compromised devices.

   This document details the process which occurs when a device is
   detected to have violated the stated policy.  The goal of these steps
   is to ensure that the device is correctly removed from operation,
   fixed, and if possible, restored to safe operation.

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 August 17, 2019.

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



Richardson & Latour      Expires August 17, 2019                [Page 1]


Internet-Draft               MUD-Quaranatine               February 2019


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  An overview of the stages of activity . . . . . . . . . .   4
   2.  Detailed description of states  . . . . . . . . . . . . . . .   5
     2.1.  New device  . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Nominal . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Suspicious  . . . . . . . . . . . . . . . . . . . . . . .   6
     2.4.  Suspect . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.5.  Device of Interest  . . . . . . . . . . . . . . . . . . .   6
     2.6.  Quarantined . . . . . . . . . . . . . . . . . . . . . . .   7
     2.7.  Disabled  . . . . . . . . . . . . . . . . . . . . . . . .   7
     2.8.  Returning to Service  . . . . . . . . . . . . . . . . . .   7
     2.9.  Owned by malicious entity ("p0wned")  . . . . . . . . . .   8
   3.  Detailed description of transitions . . . . . . . . . . . . .   8
     3.1.  Initial Enrollment  . . . . . . . . . . . . . . . . . . .   8
     3.2.  Re-enrollment . . . . . . . . . . . . . . . . . . . . . .   8
       3.2.1.  factory-default re-enrollment . . . . . . . . . . . .   8
       3.2.2.  simple re-enrollment  . . . . . . . . . . . . . . . .   9
       3.2.3.  other kinds?  . . . . . . . . . . . . . . . . . . . .   9
     3.3.  Initial suspicion . . . . . . . . . . . . . . . . . . . .   9
     3.4.  Confirmed suspicion . . . . . . . . . . . . . . . . . . .   9
     3.5.  Device identified as attack target  . . . . . . . . . . .   9
     3.6.  Suspension of connectivity  . . . . . . . . . . . . . . .   9
     3.7.  Re-Installation of valid firmware . . . . . . . . . . . .   9
   4.  An example process  . . . . . . . . . . . . . . . . . . . . .   9
   5.  Human Rights Considerations . . . . . . . . . . . . . . . . .  10
   6.  Privacy Considerations  . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     10.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11








Richardson & Latour      Expires August 17, 2019                [Page 2]


Internet-Draft               MUD-Quaranatine               February 2019


1.  Introduction

   [I-D.ietf-opsawg-mud] describes the format of the Manufacturer Usage
   Description (MUD) files.  MUD files provide a set of network Access
   Control Lists (ACL, pronounced [ak-uhl]) that describes the expected
   traffic from a device, such as an Internet of Things (IoT) device.

   MUD files are used in a number of projects, including the CIRALabs'
   [SecureHomeGateway] (SHG) project.  In this project a home gateway
   ("router") is enhanced to be able to use MUD files to describe the
   traffic expected from all connected devices.  If a device does not
   have a MUD format description, then the project can provide a broad
   set of traffic expectations based upon categorization of the device
   by the home owner.

   This document is about the process to be followed when a device is
   observed to be violating the ACLs applied to it.  While this document
   will identify network protocols (and gaps where no protocol exists)
   as appropriate, the goal of this document is more about the human
   process.  Specifically, who gets called, and in what order.  Who
   makes each call, and how are they identified.

   In addition, what kind of data needs to be shared among the parties
   and what are the privacy and human rights implications of sharing the
   required data.

   Finally, in the security considerations section of this document some
   concerns about prevention of so-called "SWAT"ing ({swatting}), where
   an attempt might be made to take a location or network offline
   through phony reports.

1.1.  Terminology

   This document is not a protocol specification, but rather a Best
   Current Practices in the area of human operations.  While this is
   sometimes called a "Standard Operating Proceedure" (SOP), this
   document should not be considered the actual SOP for an organization,
   but rather be referrenced.

   The terminology [RFC2119] the key words such as "MUST", "MUST NOT",
   "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
   "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119.  In the context of this human
   protocol, they do not describe network protocol interoperability
   requirements, but rather constraints upon how the humans need to
   operate in order to avoid unsafe situations.

   The following terms are used in this document:



Richardson & Latour      Expires August 17, 2019                [Page 3]


Internet-Draft               MUD-Quaranatine               February 2019


   o  owner's network: the network belonging to the owner of the device.
      In residentical situations, this is typically the home owner.  In
      commercial environments, this may be the owner of the building, or
      the commercial tenant in the building.

   o  tenant: one or more people who occupy a space in which a network
      of devices exists which do not belong directly to them.

1.2.  An overview of the stages of activity

   This section provides a brief overview of the states that a device
   may be in.  The following section provides a detailed description of
   the state.  This document is primarily about how a device transitions
   from one state to another, which is covered in {#transitions}.








          .--------.         .---------.<---------.------------.
          |  new   |-------->| nominal |          | suspicious |
          | device |\ .----->|         | -------->|            |
          '--------' \|      '---------'          '------------'
                      \            |
                      |\           |                    |
                      | \          |                    |
                      |  \         v                    v
                      |   \ .------------.        .-----------.
        .------------.|    v|  p0owned   |        |  suspect  |
        | returning  ||     |            |        |           |
        | to service |      '------------'        '-----------'
        '------------'             |                   |
               ^                   |                   |
               |                   v                   v
        .------------.      .------------.       .-----------.
        | upgrading  |      | quarantine |       | device-of |
        |            |<-----|            |<------| interest  |
        '------------'      '------------'       '-----------'

   Figure 1: Device Connectivity States

   o  new device: a device that has just been "connected" to the
      network.

   o  nominal: a device which is operating correctly.



Richardson & Latour      Expires August 17, 2019                [Page 4]


Internet-Draft               MUD-Quaranatine               February 2019


   o  suspicious: a device which has once gone out of it's MUD profile.

   o  suspect: a device which has repeatedly gone out of it's MUD
      profile.

   o  device-of-interest: a device that is part of a class of devices
      which is considered suspect.

   o  quarantined: a device which has been isolated into a network
      "segment", it may stil be operating locally.

   o  disabled: a device which has been disconnected from the network,
      and has also had mains power removed.  The device is believed to
      be off.

   o  upgrading: a device which is active for the purpose of having new
      firmware installed.

   o  returning-to-service: a device which has new firmware, and is
      going through a re-enrollment process.  It may still lack critical
      configuration, and may be unable to yet perform critical
      functions.

   o  p0wned: a device which is known to have malicious routines
      running, but is still connected to the network.  It may continue
      to provide the services the device was designed to do, in
      additional to performing functions controlled by an unauthorized
      entity.

2.  Detailed description of states

   A device is considered to be on one of the above states.  The device
   is not considered to be aware of it's state, rather this is a
   characteristic that the network assigns to the device.

2.1.  New device

   A device newly installed will have no initial network connectivity.
   It will be awaiting some kind of enrollment or onboarding process.
   Examples of enrollment processes include
   [I-D.ietf-anima-bootstrapping-keyinfra], [dpp], processes defined by
   The Thread Group and Apple Homekit, as well as a great number of
   custom and proprietary methods.

   In many cases the device may provide limited network connectivity
   (such as by running as an Access Point), and can be reached by
   attackers.  The owner of the device may in fact in unaware that the
   device is "smart", and it may be possible for a device to become



Richardson & Latour      Expires August 17, 2019                [Page 5]


Internet-Draft               MUD-Quaranatine               February 2019


   compromised without ever having joined a network.  This case is
   particularly difficult, as having never joined a network, the device
   will not emit signals on the owner's network that can be detected to
   notice that the device has been attacked.  Also, having never been
   connected, the device is more likely to have old firmware.

2.2.  Nominal

   The device is operating normally and is not suspected to be corrupted
   or under attack.

2.3.  Suspicious

   The device and/or the Internet has attempted a connection which is
   forbidden by the MUD file.  This activity is notable, but
   particularly in the case where a MUD file was generated by a third
   party (such as by a period of observation), it may signal that the
   MUD file is inaccurate rather than that the device is compromised.

   In the case of connections that originate from the Internet to the
   device which are forbidden, this may indicate that device is being
   scanned for, but that the security features of the router are
   resisting the attack.

   It is unclear how a device is returned from suspicious state to
   nominal.  A reasonable process might be that after a period of time
   in which no new unwanted activity occurs it is returned.  A clear
   indication that it should return to nomimal is if a new MUD file is
   applied to the device.

2.4.  Suspect

   The device is repeatedly attempting to connect to core infrastructure
   which it has reasonably no reason to connect to.  Examples of this
   would include connecting to many IP addresses in a sequential or
   high-frequency rate, connecting to well-known ports not intended to
   for end devices (for instance TCP port 22, 23, 25).  There might
   still be a reasonable explanation for this behaviour, including that
   the "inside" IP address has been reassigned to a different device
   (such as desktop computer).

2.5.  Device of Interest

   A device has become interesting based upon two possible situations:
   an internal signal that a device has become suspected, and based upon
   external indications that there are active threats against the
   device.  A device in this state SHOULD go into quarantine upon the
   next observed attack.



Richardson & Latour      Expires August 17, 2019                [Page 6]


Internet-Draft               MUD-Quaranatine               February 2019


   If it can be observed that there are DNS spoofing attempts against
   the device manufacturer's firmware repository, or it's command/
   control channel (for devices which have cloud connections), then it
   would be reasonable to become interested in the device: an attack may
   be coming.

   A device under interest would continue to be able to perform it's
   normal functions.  For instance, a furnace would continue to heat the
   house, and would continue to report it's statistics to it's
   manufacturer/service-entity, and would continue to respond to
   thermostat changes.

2.6.  Quarantined

   A device in quarantine gets no Internet or owner network access.

   A device in quarantine MAY do DNS requests to the local recursive DNS
   resolvers for the IP address of it's firmware repository.  This
   address would be present in the device's MUD file using the
   [I-D.richardson-shg-mud-quarantined-access].  Access to the firmware
   repository is important to permit the device to apply new firmware
   and/or reset itself to factory default.

   A device in quarantine that performs other functions might continue
   to be perform those functions.  For instance, a fridge would remain
   cold, but it would not respond to thermostat changes, or communicate
   with a grocery store.

2.7.  Disabled

   A device that is disabled gets no network connectivity at all,
   including no local network connectivity.

   A device that is directly mains powered would be disconnected by a
   human.  A device that is powered by Power-over-Ethernet could be
   disconnected by administratively turning power off on that port.

   A device that is battery powered or scavanges power would remain on
   as long as it had power.

2.8.  Returning to Service

   A device that is attempting to return to service has installed some
   "fix" for the issue that lead it to be quarantined.  It could also be
   the case that the device did not need to anything, and that the
   quarantine was a false positive, and a new MUD file is loaded with
   the additionally accepted patterns.




Richardson & Latour      Expires August 17, 2019                [Page 7]


Internet-Draft               MUD-Quaranatine               February 2019


   A device returning to service MAY have erased all it's network
   settings, and will have to go through some form of network enrollment
   again.

2.9.  Owned by malicious entity ("p0wned")

   A device which is known to be controlled by a malicious entity.  It
   may be impossible to quarantine the device if it performs some
   critical function and the imposition of quarantine would prevent
   that.

3.  Detailed description of transitions

   This section deals with the transitions between states.  These
   transitions occur as a result of network and/or human signaling.  The
   occurance of these transitions will in most cases cause a signal to
   be sent.

3.1.  Initial Enrollment

   The process of enrollment is out of scope for this document.

3.2.  Re-enrollment

   The process of re-enrollment is out of scope for this document.  This
   document does specify when this re-enrollment can take place, and how
   a human can indicate to a device and to the network infrastructure
   that re-enrollment can take place.

   Re-enrollment can occur a number of different ways.

3.2.1.  factory-default re-enrollment

   A device can re-enroll in a factory-default state.  This means that
   all settings are lost and any private keys that might have been
   visible to malicious code/coders who may have had access to the
   device have are regenerated.

   Devices that store private keys in Trusted Platform Modules (TPM), or
   in Trusted Execution Environments (see [I-D.ietf-teep-architecture])
   could reasonably assume that private keys may be retained.  From an
   802.1AR perspective, the IDevID may be assumed to be intact, but the
   integrity of the LDevID may be suspect.

   As the device is in a factory-default state it will have no user/
   owner-specific configuration, and any authorization lists will need
   to be re-established!




Richardson & Latour      Expires August 17, 2019                [Page 8]


Internet-Draft               MUD-Quaranatine               February 2019


3.2.2.  simple re-enrollment

   The device does not return to a factory-default state, and has
   existing network, owner credentials and configuration intact.  A
   network onboarding will need to be repeated to establish new per-
   device network keys.

   An audit of the device authorizations SHOULD be done, as an attacker
   may have inserted additional authorizations in order to return.

3.2.3.  other kinds?

   Are there states in between these two extremes?

3.3.  Initial suspicion

   The transition from nomimal to initial suspicion occurs when the MUD
   firewall detects (and blocks) network not described in the device
   MUD.  There are a number of non-critical reasons why this could
   occur.

   The mostly likely situation is that the MUD describes access rules
   using DNS names, while the firewall is implemented in terms of IP
   addresses.  The name to IP mapping may well have changed, and the
   firewall has not yet caught up to the new mapping.

3.4.  Confirmed suspicion

   TBD

3.5.  Device identified as attack target

   TBD

3.6.  Suspension of connectivity

   TBD

3.7.  Re-Installation of valid firmware

   TBD

4.  An example process

   Here will be somes examples of a device.






Richardson & Latour      Expires August 17, 2019                [Page 9]


Internet-Draft               MUD-Quaranatine               February 2019


5.  Human Rights Considerations

   TBD

6.  Privacy Considerations

   TBD

7.  Security Considerations

   TBD

8.  IANA Considerations

   No IANA objects are required.

9.  Acknowledgements

10.  References

10.1.  Normative References

   [I-D.ietf-opsawg-mud]
              Lear, E., Droms, R., and D. Romascanu, "Manufacturer Usage
              Description Specification", draft-ietf-opsawg-mud-25 (work
              in progress), June 2018.

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

10.2.  Informative References

   [dpp]      "Device Provisioning Protocol Specification", n.d.,
              <https://www.wi-fi.org/downloads-registered-guest/Device_P
              rovisioning_Protocol_Draft_Technical_Specification_Package
              _v0_0_23_0.zip/31255>.

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
              S., and K. Watsen, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-18 (work in progress), January 2019.







Richardson & Latour      Expires August 17, 2019               [Page 10]


Internet-Draft               MUD-Quaranatine               February 2019


   [I-D.ietf-teep-architecture]
              Pei, M., Tschofenig, H., Wheeler, D., Atyeo, A., and D.
              Liu, "Trusted Execution Environment Provisioning (TEEP)
              Architecture", draft-ietf-teep-architecture-01 (work in
              progress), October 2018.

   [I-D.richardson-shg-mud-quarantined-access]
              Richardson, M., "Manufacturer Usuage Description for
              quarantined access to firmware", draft-richardson-shg-mud-
              quarantined-access-00 (work in progress), January 2019.

   [looneytunes]
              "List of Looney Tunes Cartoons", n.d.,
              <https://en.wikipedia.org/wiki/
              List_of_Looney_Tunes_and_Merrie_Melodies_characters>.

   [SecureHomeGateway]
              "CIRALabs Secure Home Gateway", n.d.,
              <https://github.com/CIRALabs/>.

   [swatting]
              "Cambridge English Dictionary: swatting", January 2019,
              <https://dictionary.cambridge.org/dictionary/english/
              swatting>.

Authors' Addresses

   Michael Richardson
   Sandelman Software Works

   Email: mcr+ietf@sandelman.ca


   Jacques Latour
   CIRA Labs

   Email: Jacques.Latour@cira.ca














Richardson & Latour      Expires August 17, 2019               [Page 11]


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