Time To End The War on Network Protection
draft-lear-network-helps-00

Network Working Group                                            E. Lear
Internet-Draft                                          October 29, 2016
Intended status: Informational
Expires: May 2, 2017

               Time To End The War on Network Protection
                    draft-lear-network-helps-00.txt

Abstract

   Since the Edward Snowden's release of secret information, some in the
   IETF have taken an approach that the network is such a useful tool
   that it is also an enemy.  With several high visibility attacks that
   have been based on low end systems (Things), it is now clear that not
   only is the network not the enemy.  When the network has at least
   some information about a device, we get a second chance to limit
   attacks against the device and, in some cases, a third chance to
   limit attacks from the device.  This memo discusses ways in which
   network protection assists in protection of devices, and some caveats
   around that protection, and suggests considerations implementers and
   protocol developers should consider as connectivity continues to
   expand to new applications.

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 http://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 May 2, 2017.

Copyright Notice

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

Lear                       Expires May 2, 2017                  [Page 1]
Internet-Draft          Network Protection Helps            October 2016

   (http://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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  What might be shared (and why)  . . . . . . . . . . . . . . .   3
     2.1.  Application-layer information sharing in flight . . . . .   3
     2.2.  Transport Layer information . . . . . . . . . . . . . . .   4
     2.3.  IP Layer Information  . . . . . . . . . . . . . . . . . .   5
     2.4.  Sharing of Device Profile Information . . . . . . . . . .   5
   3.  How Information Sharing Could Stop Some Attacks . . . . . . .   6
     3.1.  DVRs  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2.  Electrical Grid Attacks . . . . . . . . . . . . . . . . .   7
     3.3.  Mobile Medical Devices  . . . . . . . . . . . . . . . . .   8
     3.4.  Mobile Phones . . . . . . . . . . . . . . . . . . . . . .   8
   4.  Encryption and Sharing  . . . . . . . . . . . . . . . . . . .   8
   5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  Example MUD File for a DVR . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12

1.  Introduction

   In June of 2013 Edward Snowden released a vast trove of secret NSA
   documents that demonstrated numerous vulnerabilities of the Internet
   architecture, that included collection of aggregate information,
   tapping of communication lines, hacking of devices in transit, and
   other means.  Many of these vulnerabilities were known to be possible
   in theory, although the scale of such an attack was unprecedented.

   The Internet Architecture Board held a plenary meeting in November
   2013 in which we openly discussed these attacks, and what we would do
   about them.  The result was [RFC7258], which states that pervasive
   surveillance should be treated formally as a form of attack.

   Since that time HTTP2 has been released, and work has begun on QUIC
   [QUIC], a transport protocol that reside atop UDP.

Lear                       Expires May 2, 2017                  [Page 2]
Internet-Draft          Network Protection Helps            October 2016

   The premise of much of this work has been that if the network has
   visibility to ANY meta-information, then it is possible for a
   government or other similarly well-funded entity to effect a
   pervasive surveillance attack.  The conclusion in some minds has been
   that the network has aided and abetted attackers to the point that
   its indistinguishable from an attacker.  A natural, yet flawed,
   conclusion was endpoints alone can and must be responsible for their
   own protection.

   Since 2013, the Internet of Things has come into its own, as
   connection capabilities have developed on everything from dolls to
   door bells.  While the ability to connect to the Internet has
   developed, ability to maintain a secure device has not kept up.  If
   the network cannot be part of the solution, and the device is unable
   to secure itself, then the device by definition will be open to
   attack.

   This document is structured as follows.  First Section 2 provides a
   general overview of the value and risks of sharing at various layer.
   Next Section 3 provides an overview of different classes of devices
   and the forms of attacks that occur where some amount of sharing
   might have provided some useful defense.  We then review the role of
   encryption in Section 4.  A basic principle is that information
   sharing should take place as a matter, and not as an accident, of
   design.

   Finally we make recommendations for how devices and networks should
   collaborate under several different use cases.

   This document considers how to address privacy considerations
   [RFC6973] in the context of Things.  While we do not pull terminology
   from that document, the concepts should be readily identifiable.

2.  What might be shared (and why)

   Within the Internet architecture it is possible for any piece of
   information to be shared.  This includes application-layer
   information, TCP/UDP port information, source/destination IP
   addresses, intended communication direction, and L2 information.  In
   addition to information shared in flight, profile information can
   also be shared.  The following discussion motivates why these pieces
   of information might be shared.

2.1.  Application-layer information sharing in flight

   When application information is shared with a firewall or similar
   system, that system is in a position to validate application layer
   exchanges for correctness.  For example, an end-to-end banking

Lear                       Expires May 2, 2017                  [Page 3]
Internet-Draft          Network Protection Helps            October 2016

   transaction authorized by a trader may be open to audit in order to
   avoid fraud, or the setting of a valve in an oil well should be
   validated to be within a set of parameters in order to avoid a spill
   or worse.  Some content discrimination may be necessary.  For
   instance, some parameters may be transparent and others encrypted.
   The trader's order might be clear, but authentication information
   would be encrypted.

   The challenge with this approach are threefold:

   o  The network access point and the end points must have an identical
      and up-to-date semantic understanding of the information being
      shared.

   o  In addition, the level of trust conferred to the network access
      point is absolute.  If it is compromised, all information is
      revealed.

   o  This level of sharing also presents scaling problems whereby the
      network must expend processing power to determine appropriate
      actions.

   When such an approach is used, it must be explicitly configured, and
   there must be an automated means to update both end points and
   network access points such that transactions are always properly
   interpreted by all parties.  In addition, appropriate resources must
   be available on the network access points.

2.2.  Transport Layer information

   At this layer service information is revealed.  This might indicate
   what applications are running in some instances, but not the content
   being exchanged.  Layer 4 is generally considered to be so-called
   "meta-information", although it is information that is exposed,
   nonetheless.  Sharing of Layer 4 information generally provides
   network access points with a basic understanding of services the
   device is using.  Combined with directional information, sharing at
   this layer usually is sufficient to indicate which end has initiated
   a conversation.  The simplest example is TCP packets that have or
   lack the ACK flag.  More advance forms retain flow state.

   Directionality is a key ingredient to being able to stop unwanted
   traffic, including malware.  Simply put, "if I didn't ask for it, I
   don't want it."  Now we apply this axiom in the context of the
   firehose we call the Internet.  Directionality can be detected in the
   transport layer and as a function of the first packet seen from a
   particular interface.  Each of these mechanisms has limitations, but
   each provides some level of protection.  Directionality is

Lear                       Expires May 2, 2017                  [Page 4]
Internet-Draft          Network Protection Helps            October 2016

   particularly important in environments where highly constrained
   devices can have their resources overwhelmed or drained, a simple
   example being an energy-harvesting light switch.  Only the network
   can enforce an approach if an end node listens to any traffic at all.

   A common pattern of communication for devices is that they would need
   DNS, NTP and perhaps either outbound or inbound web services.  Use of
   protocols like Port Control Protocol (PCP) [RFC6887] is predicated on
   the assumption that meaningful protection is provided by restricting
   access to other ports.

   This information is not quite as sensitive as application layer
   information, in that usernames, passwords, and other private pieces
   of information usually are not available to be exchanged.  Processing
   requirements at this layer vary based on the transport protocol used
   and the level of protection required.

2.3.  IP Layer Information

   The IP layer consists of source and destination addresses.  This
   information can be considerably more revealing than transport layer
   information.  Based on this information, an observer may often
   discern who the parties of a communication are, based on reverse
   address lookups or by examination of the IPv6 Interface
   Identifier(IID).  IP addresses are, conversely, the primary
   discriminators that many firewalls use to determine whether a
   communication should be allowed.  A common design pattern is that an
   system may offer a certain set of inbound services, perhaps even from
   anywhere, communicate outbound to a certain set of devices, and then
   not require any other communications.  Many firewall rule sets are
   built upon this premise.

   Cloud-based applications that make use of short TTL values of DNS
   records for load distribution have changed the nature of this game
   somewhat in that it is no longer sufficient to simply attend to IP
   addresses to authorize a service- one must also pay attention to an
   ever-changing mapping between address and name.

   IP addresses also provide some hint at geographic location.  This
   function is used today for many purposes, such as determining
   timezones or rights to certain content.  That location information
   may be abused to track individuals.

2.4.  Sharing of Device Profile Information

   A device profile consists of information that describes what a device
   does.  That information may be of a general nature shared by a
   manufacturer such as Manufacturer Usage Descriptions (MUD)

Lear                       Expires May 2, 2017                  [Page 5]
Internet-Draft          Network Protection Helps            October 2016

   [I-D.ietf-opsawg-mud] or it may be of a more specific nature unique
   to an individual deployment or owner.  The more specific the
   information revealed, the more sensitive.  For instance, telling the
   network that a device is a printer may reveal very little.  Telling
   the network that it is Eliot Lear's printer reveals ownership, and
   that he may have some relationship to the location in which the
   printer resides (like perhaps owning the or renting it).

   General information along the lines of MUD provides no information
   about who owns the device, but does reveal what the device is.
   However, with the information, a network access point is in a positon
   to apply an appropriate set of access lists to limit the scope of
   attack against the end node.

   Who has access to this information will depend on the means in which
   the profile is communicated.  For instance, if a device inventory
   system makes use of TLS, the information is shared only with that
   system.  The same can be used if information is shared over EAP-TLS
   [RFC5216].

3.  How Information Sharing Could Stop Some Attacks

3.1.  DVRs

   One recent attack based on the Mirai code [Krebs-MIRAI] that was made
   available on Github address itself to digital video recorders,
   cameras, and home Internet routers.  Some of these devices are said
   to be old and not upgradable.  Attempts to take over the device
   occurred through known telnet, SSH, and HTTP where known passwords
   were used.  It is also said that these devices, in their normal
   function, make use of one or two ports.

   Had the device manufacturer made use of Manufacturer Usage
   Descriptions (MUD), an access point could have blocked them from
   accessing the DVR, even though it had old firmware.  An Example MUD
   file is given in Appendix A.  Note that this file may not have
   stopped an already-infected device from attacking, and it requires
   that local deployment information be filled in for the class named
   "http://dvr264.example.com/controller".

   As [I-D.ietf-opsawg-mud] specifies, there are numerous ways for a
   device to indicate the URL by which to retrieve that file.  Some of
   those methods might reveal to an observer the type of device.  To
   generalize guidance in this space we might say the following of
   network devices:

   o  Information about a device should not be volunteered in insecure
      environments.

Lear                       Expires May 2, 2017                  [Page 6]
Internet-Draft          Network Protection Helps            October 2016

   o  Where possible, such information should be encrypted to an
      authorized recipient.

   o  Information that is intended for a router, such as DHCP requests,
      should only be forwarded to authorized DHCP servers, and not to
      all ports on a network.

   As we will discuss below, it may not always be possible to encrypt
   information.  Thus a risk tradeoff must be made: will the information
   cause substantial harm through leakage.  In the case of DHCP, the
   risk is that a local device is eavesdropping.  However, in this
   circumstance, even if the device emitted a DHCP option that was
   broadcast to all local devices, there would have been no additional
   damage, because a probe was used to determine that a device was
   vulnerable.  As we raise the bar, however, we may wish to consider
   how to better protect such information through the use of other
   mechanisms.

3.2.  Electrical Grid Attacks

   A large country has already seen its electrical grid attacked.  The
   attack was multifaceted, but specifically targeted the industrial
   control systems (ICSes).  In one attack, breakers were opened to
   cause a failure.  If the network between the control system and the
   circuit breaker actuator were gatewayed by a firewall observing
   commands, that attack may well have been thwarted.  As discussed
   above, such protection comes at a high cost.  In particular, the
   firewall itself becomes a point of attack.  It also requires that the
   firewall understands not only the commands, but how and when it is
   safe for them to be executed.  A poorly configured firewall might
   prevent a necessary emergency shutdown.

   Thus we might derive some general rules of thumb regarding use of
   application information:

   o  These mechanisms should, when at all possible, be explicitly
      authorized, where encryption is used between all components.

   o  Where encryption is not possible, substantial additional levels of
      security should be placed around the control system so as to
      otherwise limit unauthorized access.  This might include, for
      instance, a limitation on remote connectivity or use of VPNs,
      where access of the physical communication path cannot be
      controlled.

   o  There must be clear parameters as to what reasonable values are,
      and what to do in exceptional circumstances.

Lear                       Expires May 2, 2017                  [Page 7]
Internet-Draft          Network Protection Helps            October 2016

3.3.  Mobile Medical Devices

   A number of medical devices that have transceivers may now be
   implanted in humans.  These devices are as mobile as their patients
   are.  Such devices may be subject to nearly all classes of attack,
   such as unauthorized access to denial of service.  All such attacks
   could prove deadly to the patient.  The problem is complicated by the
   fact that these devices are generally battery operated where intended
   communication is expected to be rare, but responsive when needed.
   One approach used to address this limitation is to only enable near
   field communications, so that remote attacks are not possible.
   Another is to require a magnetic field to enable remote access, as is
   done with pacemakers.  In these cases, ad hoc connectivity is then
   established.  Examining the threat model, if someone is going to
   attack a person with a magnet, they may well have other ways to
   effect an attack.  The key is that the magnet is essentially used as
   an electrical switch to enable communication.  Having some local
   activation mechanism can prevent resource drain, where no information
   is gratuitously shared.

   Such an approach may not be practicable in all circumstances.  When
   that is the case, the network should be used to detect and prevent
   denial of service attacks, without the need to reveal identifying
   about the patient.

3.4.  Mobile Phones

   Mobile phones have been well studied.  Risks associated with these
   devices often involve users taking actions not in their best
   interests, such as installing malware, or permitting excessive rights
   to an app.[EGEL12].  Mobile Service providers typically already have
   information as to devices attached to the network, in part because
   they often sell those devices at reduced prices with contracts.

4.  Encryption and Sharing

   When data is obscured via encryption, then it must be shared
   explicitly with intended recipients.  When practicable, this is a
   preferred approach, but a number of problems often arise:

   o  Trust between parties.  While some ongoing work is exploring
      trusted introduction [I-D.ietf-anima-bootstrapping-keyinfra], due
      to memory and connectivity constraints it is often difficult to
      establish trust between two or more parties.

   o  Even once a trusted introduction has occurred, ongoing key
      management and algorithm selection remains a challenge.  The
      entire device lifecycle must be taken into account.

Lear                       Expires May 2, 2017                  [Page 8]
Internet-Draft          Network Protection Helps            October 2016

   Because of poor interactions between network components and devices,
   many services now reside on TCP port 443, meaning that when
   encryption is possible, it is not possible for a firewall to filter
   based on service as it has been in the past.

   In order to avoid tracking, a number of mobile devices are now
   regularly changing their L2 MAC addresses, where possible.  This
   makes filtering based on MAC address impracticable.  Similarly,
   devices deploying IPv6 have the ability to make use of different IPv6
   Interface Identifier (IID).  [RFC7721] discusses the privacy
   implications and threats of using stable IIDs.  As that document
   mentions, if the IID is part of an authentication paradigm, its
   change means that the device itself must be reauthenticated, and may
   add to system fragility.

5.  Conclusions

   When networks take on certain functions there are some risks that
   must be considered.  The same is true when only devices attempt to
   provide for their own security.  An systemic and architectural
   approach is needed that makes use of both device and network
   capabilities in good measure.  Such an approach must take into
   account both privacy and security requirements, where appropriate
   balances can be made.

6.  Security Considerations

   This document discusses the security of the Internet.

7.  IANA Considerations

   This section may be removed upon publication.  There are no IANA
   considerations.

8.  Acknowledgments

9.  Informative References

   [EGEL12]   Egelman, S., Felt, A., and D. Wagner, "Choice Architecture
              and Smartphone Privacy: There's A Price for That", 2012,
              <http://www.econinfosec.org/archive/weis2012/papers/
              Egelman_WEIS2012.pdf>.

   [I-D.ietf-anima-bootstrapping-keyinfra]
              Pritikin, M., Richardson, M., Behringer, M., and S.
              Bjarnason, "Bootstrapping Remote Secure Key
              Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
              keyinfra-03 (work in progress), June 2016.

Lear                       Expires May 2, 2017                  [Page 9]
Internet-Draft          Network Protection Helps            October 2016

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

   [Krebs-MIRAI]
              "Source Code for IoT Botnet 'Mirai' Released", October
              2016, <https://krebsonsecurity.com/2016/10/source-code-
              for-iot-botnet-mirai-released/>.

   [QUIC]     "QUIC Working Group Charter", 2016,
              <https://datatracker.ietf.org/wg/quic/charter/>.

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216,
              March 2008, <http://www.rfc-editor.org/info/rfc5216>.

   [RFC6887]  Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and
              P. Selkirk, "Port Control Protocol (PCP)", RFC 6887,
              DOI 10.17487/RFC6887, April 2013,
              <http://www.rfc-editor.org/info/rfc6887>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <http://www.rfc-editor.org/info/rfc6973>.

   [RFC7258]  Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
              Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
              2014, <http://www.rfc-editor.org/info/rfc7258>.

   [RFC7721]  Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
              Considerations for IPv6 Address Generation Mechanisms",
              RFC 7721, DOI 10.17487/RFC7721, March 2016,
              <http://www.rfc-editor.org/info/rfc7721>.

Appendix A.  Example MUD File for a DVR

   {
     "ietf-mud:meta-info": {
       "lastUpdate": "2016-10-23T14:11:52+02:00",
       "systeminfo": "DVR H.264",
       "cacheValidity": 1440
     },
     "ietf-acl:access-lists": {
       "ietf-acl:access-list": [
         {

Lear                       Expires May 2, 2017                 [Page 10]
Internet-Draft          Network Protection Helps            October 2016

           "acl-name": "mud-10387-v4in",
           "acl-type": "ipv4-acl",
           "ietf-mud:packet-direction": "to-device",
           "access-list-entries": {
             "ace": [
               {
                 "rule-name": "clout0-in",
                 "matches" : {
                    "ietf-mud:direction-initiated" : "from-device"
                    },
                 "actions": {
                   "permit": [
                     null
                   ]
                 }
               },
               {
                 "rule-name": "entin0-in",
                 "matches": {
                   "ietf-mud:controller":
                    "http://dvr264.example.com/controller",
                    "ietf-mud:direction-initiated" : "to-device"
                 },
                 "actions": {
                   "permit": [
                     null
                   ]
                 }
               }
             ]
           }
         },
         {
           "acl-name": "mud-10387-v4out",
           "acl-type": "ipv4-acl",
           "ietf-mud:packet-direction": "from-device",
           "access-list-entries": {
             "ace": [
               {
                 "rule-name": "clout0-in",
                 "matches": {
                    "ietf-mud:direction-initiated" : "from-device"
                 },
                 "actions": {
                   "permit": [
                     null
                   ]
                 }

Lear                       Expires May 2, 2017                 [Page 11]
Internet-Draft          Network Protection Helps            October 2016

               },
               {
                 "rule-name": "entin0-in",
                 "matches": {
        "ietf-mud:controller":  "http://dvr264.example.com/controller",
                    "ietf-mud:direction-initiated" : "to-device"
                 },
                 "actions": {
                   "permit": [
                     null
                   ]
                 }
               }
             ]
           }
         }
       ]
     }
   }

Author's Address

   Eliot Lear

   Email: lear@ofcourseimright.com

Lear                       Expires May 2, 2017                 [Page 12]