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

Versions: 00 01

Internet Engineering Task Force                               T. Mizrahi
Internet-Draft                                                   MARVELL
Intended status: Informational                          E. Grossman, Ed.
Expires: September 14, 2017                                        DOLBY
                                                               A. Hacker
                                                                  MISTIQ
                                                                  S. Das
                                          Applied Communication Sciences
                                                              J. Dowdell
                                                Airbus Defence and Space
                                                          March 13, 2017


       Deterministic Networking (DetNet) Security Considerations
                      draft-sdt-detnet-security-00

Abstract

   A deterministic network is one that can carry data flows for real-
   time applications with extremely low data loss rates and bounded
   latency.  Deterministic networks have been successfully deployed in
   real-time operational technology (OT) applications for some years
   (for example [ARINC664P7]).  However, such networks are typically
   isolated from external access, and thus the security threat from
   external attackers is low.  IETF Deterministic Networking (DetNet)
   specifies a set of technologies that enable creation of deterministic
   networks on IP-based networks of potentially wide area (on the scale
   of a corporate network) potentially bringing the OT network into
   contact with Information Technology (IT) traffic and security threats
   that lie outside of a tightly controlled and bounded area (such as
   the internals of an aircraft).  These DetNet technologies have not
   previously been deployed together on a wide area IP-based network,
   and thus can present security considerations that may be new to IP-
   based wide area network designers.  This draft, intended for use by
   DetNet network designers, provides insight into these security
   considerations.  In addition, this draft collects all security-
   related statements from the various DetNet drafts (Architecture, Use
   Cases, etc) into a single location Section 4.

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



Mizrahi, et al.        Expires September 14, 2017               [Page 1]


Internet-Draft               DetNet Security                  March 2017


   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 14, 2017.

Copyright Notice

   Copyright (c) 2017 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
   (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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Abbreviations . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Security Threats  . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .   5
     3.2.  Threat Analysis . . . . . . . . . . . . . . . . . . . . .   5
       3.2.1.  Threats Related to Delay  . . . . . . . . . . . . . .   5
         3.2.1.1.  Delay Attack  . . . . . . . . . . . . . . . . . .   5
       3.2.2.  Threats Related to DetNet Flow Identification . . . .   5
         3.2.2.1.  DetNet Flow Modification or Spoofing  . . . . . .   6
       3.2.3.  Threats Related to Resource Segmentation or Slicing .   6
         3.2.3.1.  Inter-segment Attack  . . . . . . . . . . . . . .   6
       3.2.4.  Threats Related to Packet Replication and Elimination   6
         3.2.4.1.  Replication: Increased Attack Surface . . . . . .   6
         3.2.4.2.  Replication-related Header Manipulation . . . . .   6
       3.2.5.  Threats Related to Path Choice  . . . . . . . . . . .   7
         3.2.5.1.  Path Manipulation . . . . . . . . . . . . . . . .   7
         3.2.5.2.  Path Choice: Increased Attack Surface . . . . . .   7
       3.2.6.  Threats Related to the Control Plane  . . . . . . . .   7
         3.2.6.1.  Control or Signaling Packet Modification  . . . .   7
         3.2.6.2.  Control or Signaling Packet Injection . . . . . .   7
       3.2.7.  Threats Related to Scheduling or Shaping  . . . . . .   7
         3.2.7.1.  Reconnaissance  . . . . . . . . . . . . . . . . .   8
       3.2.8.  Threats Related to Time Synchronization Mechanisms  .   8
     3.3.  Threat Summary  . . . . . . . . . . . . . . . . . . . . .   8



Mizrahi, et al.        Expires September 14, 2017               [Page 2]


Internet-Draft               DetNet Security                  March 2017


   4.  Appendix A: DetNet Draft Security-Related Statements  . . . .   9
     4.1.  Architecture (draft 8)  . . . . . . . . . . . . . . . . .   9
       4.1.1.  Fault Mitigation (sec 4.5)  . . . . . . . . . . . . .   9
       4.1.2.  Security Considerations (sec 7) . . . . . . . . . . .  10
     4.2.  Data Plane Alternatives (draft 4) . . . . . . . . . . . .  11
       4.2.1.  Security Considerations (sec 7) . . . . . . . . . . .  11
     4.3.  Problem Statement (draft 5) . . . . . . . . . . . . . . .  11
       4.3.1.  Security Considerations (sec 5) . . . . . . . . . . .  11
     4.4.  Use Cases (draft 11)  . . . . . . . . . . . . . . . . . .  12
       4.4.1.  (Utility Networks) Security Current Practices and
               Limitations (sec 3.2.1) . . . . . . . . . . . . . . .  12
       4.4.2.  (Utility Networks) Security Trends in Utility
               Networks (sec 3.3.3)  . . . . . . . . . . . . . . . .  13
       4.4.3.  (BAS) Security Considerations (sec 4.2.4) . . . . . .  15
       4.4.4.  (6TiSCH) Security Considerations (sec 5.3.3)  . . . .  15
       4.4.5.  (Cellular radio) Security Considerations (sec 6.1.5)   15
       4.4.6.  (Industrial M2M) Communication Today (sec 7.2)  . . .  16
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  16
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   7.  Informative References  . . . . . . . . . . . . . . . . . . .  16
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  16

1.  Introduction

   Security is of particularly high importance in DetNet networks
   because many of the use cases which are enabled by DetNet
   [I-D.ietf-detnet-use-cases] include control of physical devices
   (power grid components, industrial controls, building controls) which
   can have high operational costs for failure, and present potentially
   attractive targets for cyber-attackers.

   This situation is even more acute given that one of the goals of
   DetNet is to provide a "converged network", i.e. one that includes
   both IT traffic and OT traffic, thus exposing potentially sensitive
   OT devices to attack in ways that were not previously common (usually
   because they were under a separate control system or othewise
   isolated from the IT network).  Security considerations for OT
   networks is not a new area, and there are many OT networks today that
   are connected to wide area networks or the Internet; this draft
   focuses on the issues that are specific to the DetNet technologies
   and use cases.

   This initial version of this draft consists of a threat model and
   analysis, and in the future will be expanded to include mitigation
   strategies.

   This draft also provides context for the DetNet security
   considerations by collecting into one place Section 4 the various



Mizrahi, et al.        Expires September 14, 2017               [Page 3]


Internet-Draft               DetNet Security                  March 2017


   remarks about security from the various DetNet drafts (Use Cases,
   Architecture, etc).  This text is duplicated here primarily because
   the DetNet working group has elected not to produce a Requirements
   draft and thus collectively these statements are as close as we have
   to "DetNet Security Requirements".

   The DetNet technologies include ways to:

   o  Reserve data plane resources for DetNet flows in some or all of
      the intermediate nodes (e.g. bridges or routers) along the path of
      the flow

   o  Provide explicit routes for DetNet flows that do not rapidly
      change with the network topology

   o  Distribute data from DetNet flow packets over time and/or space to
      ensure delivery of each packet's data' in spite of the loss of a
      path

2.  Abbreviations

   IT         Information technology (the application of computers to
   store, study, retrieve, transmit, and manipulate dataor information,
   often in the context of a business or other enterprise - Wikipedia).

   OT         Operational Technology (the hardware and software
   dedicated to detecting or causing changes in physical processes
   through direct monitoring and/or control of physical devices such as
   valves, pumps, etc. - Wikipedia)

   MITM       Man in the Middle

   SN         Sequence Number

   STRIDE       Addresses risk and severity associated with threat
   categories: Spoofing identity, Tampering with data, Repudiation,
   Information disclosure, Denial of service, Elevation of privilege.

   DREAD       Compares and prioritizes risk represented by these threat
   categories: Damage potential, Reproducibility, Exploitability, how
   many Affected users, Discoverablility.

   PTP         Precision Time Protocol [IEEE1588]








Mizrahi, et al.        Expires September 14, 2017               [Page 4]


Internet-Draft               DetNet Security                  March 2017


3.  Security Threats

   This section presents a threat model, and analyzes the possible
   threats in a DetNet-enabled network.

   We distinguish control plane threats from data plane threats.  The
   attack surface may be the same, but the types of attacks are
   different.  For example, a delay attack is more relevant to data
   plane than to control plane.  There is also a difference in terms of
   security solutions: the way you secure the data plane is often
   different than the way you secure the control plane.

3.1.  Threat Model

   The threat model used in this memo is based on the threat model of
   Section 3.1 of [RFC7384].  This model is briefly presented in this
   subsection.

   The model classifies attackers based on two criteria:

   o  Internal vs. external: internal attackers either have access to a
      trusted segment of the network or possess the encryption or
      authentication keys.  External attackers, on the other hand, do
      not have the keys and have access only to the encrypted or
      authenticated traffic.

   o  Man in the Middle (MITM) vs. packet injector: MITM attackers are
      located in a position that allows interception and modification of
      in-flight protocol packets, whereas a traffic injector can only
      attack by generating protocol packets.

3.2.  Threat Analysis

3.2.1.  Threats Related to Delay

3.2.1.1.  Delay Attack

   An attacker can maliciously delay DetNet data flow traffic.  By
   delaying the traffic, the attacker can compromise the service of
   applications that are sensitive to high delays or to high delay
   variation.

3.2.2.  Threats Related to DetNet Flow Identification








Mizrahi, et al.        Expires September 14, 2017               [Page 5]


Internet-Draft               DetNet Security                  March 2017


3.2.2.1.  DetNet Flow Modification or Spoofing

   An attacker can modify some header fields of en route packets in a
   way that causes the DetNet flow identification mechanisms to
   misclassify the flow.  Alternatively, the attacker can inject traffic
   that is tailored to appear as if it belongs to a legitimate DetNet
   flow.  The potential consequence is that the DetNet flow resource
   allocation cannot guarantee the performance that is expected when the
   flow identification works correctly.

   Note that in some cases there may be an explicit DetNet header, but
   in some cases the flow identification may be based on fields from the
   L3/L4 headers.  If L3/L4 headers are involved, for purposes of this
   draft we assume they are encrypted and/or integrity-protected from
   external attackers.

3.2.3.  Threats Related to Resource Segmentation or Slicing

3.2.3.1.  Inter-segment Attack

   An attacker can inject traffic, consuming network device resources,
   thereby affecting DetNet flows.  This can be performed using non-
   DetNet traffic that affects DetNet traffic, or by using DetNet
   traffic from one DetNet flow that affects traffic from different
   DetNet flows.

3.2.4.  Threats Related to Packet Replication and Elimination

3.2.4.1.  Replication: Increased Attack Surface

   Redundancy is intended to increase the robustness and survivability
   of DetNet flows, and replication over multiple paths can potentially
   mitigate an attack that is limited to a single path.  However, the
   fact that packets are replicated over multiple paths increases the
   attack surface of the network, i.e., there are more points in the
   network that may be subject to attacks.

3.2.4.2.  Replication-related Header Manipulation

   An attacker can manipulate the replication-related header fields
   (R-TAG).  This capability opens the door for various types of
   attacks.  For example:

   o  Forward both replicas - malicious change of a packet SN (Sequence
      Number) can cause both replicas of the packet to be forwarded.
      Note that this attack has a similar outcome to a replay attack.





Mizrahi, et al.        Expires September 14, 2017               [Page 6]


Internet-Draft               DetNet Security                  March 2017


   o  Eliminate both replicas - SN manipulation can be used to cause
      both replicas to be eliminated.  In this case an attacker that has
      access to a single path can cause packets from other paths to be
      dropped, thus compromising some of the advantage of path
      redundancy.

   o  Flow hijacking - an attacker can hijack a DetNet flow with access
      to a single path by systematically replacing the SNs on the given
      path with higher SN values.  For example, an attacker can replace
      every SN value S with a higher value S+C, where C is a constant
      integer.  Thus, the attacker creates a false illusion that the
      attacked path has the lowest delay, causing all packets from other
      paths to be eliminated.  Once the flow is hijacked the attacker
      can either replace en route packets with malicious packets, or
      simply injecting errors, causing the packets to be dropped at
      their destination.

3.2.5.  Threats Related to Path Choice

3.2.5.1.  Path Manipulation

   An attacker can maliciously change, add, or remove a path, thereby
   affecting the corresponding DetNet flows that use the path.

3.2.5.2.  Path Choice: Increased Attack Surface

   One of the possible consequences of a path manipulation attack is an
   increased attack surface.  Thus, when the attack described in the
   previous subsection is implemented, it may increase the potential of
   other attacks to be performed.

3.2.6.  Threats Related to the Control Plane

3.2.6.1.  Control or Signaling Packet Modification

   An attacker can maliciously modify en route control packets in order
   to disrupt or manipulate the DetNet path/resource allocation.

3.2.6.2.  Control or Signaling Packet Injection

   An attacker can maliciously inject control packets in order to
   disrupt or manipulate the DetNet path/resource allocation.

3.2.7.  Threats Related to Scheduling or Shaping







Mizrahi, et al.        Expires September 14, 2017               [Page 7]


Internet-Draft               DetNet Security                  March 2017


3.2.7.1.  Reconnaissance

   A passive eavesdropper can gather information about en route DetNet
   flows, e.g., the number of DetNet flows, their bandwidths, and their
   schedules.  The gathered information can later be used to invoke
   other attacks on some or all of the flows.

3.2.8.  Threats Related to Time Synchronization Mechanisms

   An attacker can use any of the threats described in [RFC7384] to
   attack the synchronization protocol, thus affecting the DetNet
   service.

3.3.  Threat Summary

   A summary of the threats that were discussed in this section is
   presented in Figure 1.  For each threat, the table specifies the type
   of attackers that may invoke the attack.  In the context of this
   summary, the distinction between internal and external attacks is
   under the assumption that a corresponding security mechanism is being
   used, and that the corresponding network equipment takes part in this
   mechanism.





























Mizrahi, et al.        Expires September 14, 2017               [Page 8]


Internet-Draft               DetNet Security                  March 2017


   +-----------------------------------------+----+----+----+----+
   | Attack                                  |   Attacker Type   |
   |                                         +---------+---------+
   |                                         |Internal |External |
   |                                         |MITM|Inj.|MITM|Inj.|
   +-----------------------------------------+----+----+----+----+
   |Delay attack                             | +  |    | +  |    |
   +-----------------------------------------+----+----+----+----+
   |DetNet Flow Modification or Spoofing     | +  | +  |    |    |
   +-----------------------------------------+----+----+----+----+
   |Inter-segment Attack                     | +  | +  |    |    |
   +-----------------------------------------+----+----+----+----+
   |Replication: Increased Attack Surface    | +  | +  | +  | +  |
   +-----------------------------------------+----+----+----+----+
   |Replication-related Header Manipulation  | +  |    |    |    |
   +-----------------------------------------+----+----+----+----+
   |Path Manipulation                        | +  | +  |    |    |
   +-----------------------------------------+----+----+----+----+
   |Path Choice: Increased Attack Surface    | +  | +  | +  | +  |
   +-----------------------------------------+----+----+----+----+
   |Control or Signaling Packet Modification | +  |    |    |    |
   +-----------------------------------------+----+----+----+----+
   |Control or Signaling Packet Injection    |    | +  |    |    |
   +-----------------------------------------+----+----+----+----+
   |Reconnaissance                           | +  |    | +  |    |
   +-----------------------------------------+----+----+----+----+
   |Attacks on Time Sync Mechanisms          | +  | +  | +  | +  |
   +-----------------------------------------+----+----+----+----+

                     Figure 1: Threat Analysis Summary

4.  Appendix A: DetNet Draft Security-Related Statements

   This section collects the various statements in the currently
   existing DetNet Working Group drafts.  For each draft, the section
   name and number of the quoted section is shown.  The text shown here
   is the work of the original draft authors, quoted verbatim from the
   drafts.  The intention is to explicitly quote all relevant text, not
   to summarize it.

4.1.  Architecture (draft 8)

4.1.1.  Fault Mitigation (sec 4.5)

   One key to building robust real-time systems is to reduce the
   infinite variety of possible failures to a number that can be
   analyzed with reasonable confidence.  DetNet aids in the process by
   providing filters and policers to detect DetNet packets received on



Mizrahi, et al.        Expires September 14, 2017               [Page 9]


Internet-Draft               DetNet Security                  March 2017


   the wrong interface, or at the wrong time, or in too great a volume,
   and to then take actions such as discarding the offending packet,
   shutting down the offending DetNet flow, or shutting down the
   offending interface.

   It is also essential that filters and service remarking be employed
   at the network edge to prevent non-DetNet packets from being mistaken
   for DetNet packets, and thus impinging on the resources allocated to
   DetNet packets.

   There exist techniques, at present and/or in various stages of
   standardization, that can perform these fault mitigation tasks that
   deliver a high probability that misbehaving systems will have zero
   impact on well-behaved DetNet flows, except of course, for the
   receiving interface(s) immediately downstream of the misbehaving
   device.  Examples of such techniques include traffic policing
   functions (e.g.  [RFC2475]) and separating flows into per-flow rate-
   limited queues.

4.1.2.  Security Considerations (sec 7)

   Security in the context of Deterministic Networking has an added
   dimension; the time of delivery of a packet can be just as important
   as the contents of the packet, itself.  A man-in-the-middle attack,
   for example, can impose, and then systematically adjust, additional
   delays into a link, and thus disrupt or subvert a real-time
   application without having to crack any encryption methods employed.
   See [RFC7384] for an exploration of this issue in a related context.

   Furthermore, in a control system where millions of dollars of
   equipment, or even human lives, can be lost if the DetNet QoS is not
   delivered, one must consider not only simple equipment failures,
   where the box or wire instantly becomes perfectly silent, but bizarre
   errors such as can be caused by software failures.  Because there is
   essential no limit to the kinds of failures that can occur,
   protecting against realistic equipment failures is indistinguishable,
   in most cases, from protecting against malicious behavior, whether
   accidental or intentional.

   Security must cover:

   o  Protection of the signaling protocol

   o  Authentication and authorization of the controlling nodes

   o  Identification and shaping of the flows





Mizrahi, et al.        Expires September 14, 2017              [Page 10]


Internet-Draft               DetNet Security                  March 2017


4.2.  Data Plane Alternatives (draft 4)

4.2.1.  Security Considerations (sec 7)

   This document does not add any new security considerations beyond
   what the referenced technologies already have.

4.3.  Problem Statement (draft 5)

4.3.1.  Security Considerations (sec 5)

   Security in the context of Deterministic Networking has an added
   dimension; the time of delivery of a packet can be just as important
   as the contents of the packet, itself.  A man-in-the-middle attack,
   for example, can impose, and then systematically adjust, additional
   delays into a link, and thus disrupt or subvert a real-time
   application without having to crack any encryption methods employed.
   See [RFC7384] for an exploration of this issue in a related context.

   Typical control networks today rely on complete physical isolation to
   prevent rogue access to network resources.  DetNet enables the
   virtualization of those networks over a converged IT/OT
   infrastructure.  Doing so, DetNet introduces an additional risk that
   flows interact and interfere with one another as they share physical
   resources such as Ethernet trunks and radio spectrum.  The
   requirement is that there is no possible data leak from and into a
   deterministic flow, and in a more general fashion there is no
   possible influence whatsoever from the outside on a deterministic
   flow.  The expectation is that physical resources are effectively
   associated with a given flow at a given point of time.  In that
   model, Time Sharing of physical resources becomes transparent to the
   individual flows which have no clue whether the resources are used by
   other flows at other times.

   Security must cover:

   o  Protection of the signaling protocol

   o  Authentication and authorization of the controlling nodes

   o  Identification and shaping of the flows

   o  Isolation of flows from leakage and other influences from any
      activity sharing physical resources







Mizrahi, et al.        Expires September 14, 2017              [Page 11]


Internet-Draft               DetNet Security                  March 2017


4.4.  Use Cases (draft 11)

4.4.1.  (Utility Networks) Security Current Practices and Limitations
        (sec 3.2.1)

   Grid monitoring and control devices are already targets for cyber
   attacks, and legacy telecommunications protocols have many intrinsic
   network-related vulnerabilities.  For example, DNP3, Modbus,
   PROFIBUS/PROFINET, and other protocols are designed around a common
   paradigm of request and respond.  Each protocol is designed for a
   master device such as an HMI (Human Machine Interface) system to send
   commands to subordinate slave devices to retrieve data (reading
   inputs) or control (writing to outputs).  Because many of these
   protocols lack authentication, encryption, or other basic security
   measures, they are prone to network-based attacks, allowing a
   malicious actor or attacker to utilize the request-and-respond system
   as a mechanism for command-and-control like functionality.  Specific
   security concerns common to most industrial control, including
   utility telecommunication protocols include the following:

   o  Network or transport errors (e.g. malformed packets or excessive
      latency) can cause protocol failure.

   o  Protocol commands may be available that are capable of forcing
      slave devices into inoperable states, including powering-off
      devices, forcing them into a listen-only state, disabling
      alarming.

   o  Protocol commands may be available that are capable of restarting
      communications and otherwise interrupting processes.

   o  Protocol commands may be available that are capable of clearing,
      erasing, or resetting diagnostic information such as counters and
      diagnostic registers.

   o  Protocol commands may be available that are capable of requesting
      sensitive information about the controllers, their configurations,
      or other need-to-know information.

   o  Most protocols are application layer protocols transported over
      TCP; therefore it is easy to transport commands over non-standard
      ports or inject commands into authorized traffic flows.

   o  Protocol commands may be available that are capable of
      broadcasting messages to many devices at once (i.e. a potential
      DoS).





Mizrahi, et al.        Expires September 14, 2017              [Page 12]


Internet-Draft               DetNet Security                  March 2017


   o  Protocol commands may be available to query the device network to
      obtain defined points and their values (i.e. a configuration
      scan).

   o  Protocol commands may be available that will list all available
      function codes (i.e. a function scan).

   o  These inherent vulnerabilities, along with increasing connectivity
      between IT an OT networks, make network-based attacks very
      feasible.

   o  Simple injection of malicious protocol commands provides control
      over the target process.  Altering legitimate protocol traffic can
      also alter information about a process and disrupt the legitimate
      controls that are in place over that process.  A man-in-the-middle
      attack could provide both control over a process and
      misrepresentation of data back to operator consoles.

4.4.2.  (Utility Networks) Security Trends in Utility Networks (sec
        3.3.3)

   Although advanced telecommunications networks can assist in
   transforming the energy industry by playing a critical role in
   maintaining high levels of reliability, performance, and
   manageability, they also introduce the need for an integrated
   security infrastructure.  Many of the technologies being deployed to
   support smart grid projects such as smart meters and sensors can
   increase the vulnerability of the grid to attack.  Top security
   concerns for utilities migrating to an intelligent smart grid
   telecommunications platform center on the following trends:

   o  Integration of distributed energy resources

   o  Proliferation of digital devices to enable management, automation,
      protection, and control

   o  Regulatory mandates to comply with standards for critical
      infrastructure protection

   o  Migration to new systems for outage management, distribution
      automation, condition-based maintenance, load forecasting, and
      smart metering

   o  Demand for new levels of customer service and energy management

   This development of a diverse set of networks to support the
   integration of microgrids, open-access energy competition, and the
   use of network-controlled devices is driving the need for a converged



Mizrahi, et al.        Expires September 14, 2017              [Page 13]


Internet-Draft               DetNet Security                  March 2017


   security infrastructure for all participants in the smart grid,
   including utilities, energy service providers, large commercial and
   industrial, as well as residential customers.  Securing the assets of
   electric power delivery systems (from the control center to the
   substation, to the feeders and down to customer meters) requires an
   end-to-end security infrastructure that protects the myriad of
   telecommunications assets used to operate, monitor, and control power
   flow and measurement.

   "Cyber security" refers to all the security issues in automation and
   telecommunications that affect any functions related to the operation
   of the electric power systems.  Specifically, it involves the
   concepts of:

   o  Integrity : data cannot be altered undetectably

   o  Authenticity : the telecommunications parties involved must be
      validated as genuine

   o  Authorization : only requests and commands from the authorized
      users can be accepted by the system

   o  Confidentiality : data must not be accessible to any
      unauthenticated users

   When designing and deploying new smart grid devices and
   telecommunications systems, it is imperative to understand the
   various impacts of these new components under a variety of attack
   situations on the power grid.  Consequences of a cyber attack on the
   grid telecommunications network can be catastrophic.  This is why
   security for smart grid is not just an ad hoc feature or product,
   it's a complete framework integrating both physical and Cyber
   security requirements and covering the entire smart grid networks
   from generation to distribution.  Security has therefore become one
   of the main foundations of the utility telecom network architecture
   and must be considered at every layer with a defense-in-depth
   approach.  Migrating to IP based protocols is key to address these
   challenges for two reasons:

   o  IP enables a rich set of features and capabilities to enhance the
      security posture

   o  IP is based on open standards, which allows interoperability
      between different vendors and products, driving down the costs
      associated with implementing security solutions in OT networks.

   Securing OT (Operation technology) telecommunications over packet-
   switched IP networks follow the same principles that are foundational



Mizrahi, et al.        Expires September 14, 2017              [Page 14]


Internet-Draft               DetNet Security                  March 2017


   for securing the IT infrastructure, i.e., consideration must be given
   to enforcing electronic access control for both person-to-machine and
   machine-to-machine communications, and providing the appropriate
   levels of data privacy, device and platform integrity, and threat
   detection and mitigation.

4.4.3.  (BAS) Security Considerations (sec 4.2.4)

   When BAS field networks were developed it was assumed that the field
   networks would always be physically isolated from external networks
   and therefore security was not a concern.  In today's world many BASs
   are managed remotely and are thus connected to shared IP networks and
   so security is definitely a concern, yet security features are not
   available in the majority of BAS field network deployments .

   The management network, being an IP-based network, has the protocols
   available to enable network security, but in practice many BAS
   systems do not implement even the available security features such as
   device authentication or encryption for data in transit.

4.4.4.  (6TiSCH) Security Considerations (sec 5.3.3)

   On top of the classical requirements for protection of control
   signaling, it must be noted that 6TiSCH networks operate on limited
   resources that can be depleted rapidly in a DoS attack on the system,
   for instance by placing a rogue device in the network, or by
   obtaining management control and setting up unexpected additional
   paths.

4.4.5.  (Cellular radio) Security Considerations (sec 6.1.5)

   Establishing time-sensitive streams in the network entails reserving
   networking resources for long periods of time.  It is important that
   these reservation requests be authenticated to prevent malicious
   reservation attempts from hostile nodes (or accidental
   misconfiguration).  This is particularly important in the case where
   the reservation requests span administrative domains.  Furthermore,
   the reservation information itself should be digitally signed to
   reduce the risk of a legitimate node pushing a stale or hostile
   configuration into another networking node.

   Note: This is considered important for the security policy of the
   network, but does not affect the core DetNet architecture and design.








Mizrahi, et al.        Expires September 14, 2017              [Page 15]


Internet-Draft               DetNet Security                  March 2017


4.4.6.  (Industrial M2M) Communication Today (sec 7.2)

   Industrial network scenarios require advanced security solutions.
   Many of the current industrial production networks are physically
   separated.  Preventing critical flows from be leaked outside a domain
   is handled today by filtering policies that are typically enforced in
   firewalls.

5.  IANA Considerations

   This memo includes no requests from IANA.

6.  Security Considerations

   The security considerations of DetNet networks are presented
   throughout this document.

7.  Informative References

   [ARINC664P7]
              ARINC, "ARINC 664 Aircraft Data Network, Part 7, Avionics
              Full-Duplex Switched Ethernet Network", 2009.

   [I-D.ietf-detnet-use-cases]
              Grossman, E., Gunther, C., Thubert, P., Wetterwald, P.,
              Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y.,
              Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana,
              X., Mahmoodi, T., Spirou, S., and P. Vizarreta,
              "Deterministic Networking Use Cases", draft-ietf-detnet-
              use-cases-11 (work in progress), October 2016.

   [IEEE1588]
              IEEE, "IEEE 1588 Standard for a Precision Clock
              Synchronization Protocol for Networked Measurement and
              Control Systems Version 2", 2008.

   [RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
              Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
              October 2014, <http://www.rfc-editor.org/info/rfc7384>.

Authors' Addresses

   Tal Mizrahi
   Marvell

   Email: talmi@marvell.com





Mizrahi, et al.        Expires September 14, 2017              [Page 16]


Internet-Draft               DetNet Security                  March 2017


   Ethan Grossman (editor)
   Dolby Laboratories, Inc.
   1275 Market Street
   San Francisco, CA  94103
   USA

   Phone: +1 415 645 4726
   Email: ethan.grossman@dolby.com
   URI:   http://www.dolby.com


   Andrew J. Hacker
   MistIQ Technologies, Inc
   Harrisburg, PA
   USA

   Email: ajhacker@mistiqtech.com
   URI:   http://www.mistiqtech.com


   Subir Das
   Applied Communication Sciences
   150 Mount Airy Road, Basking Ridge
   New Jersey, 07920
   USA

   Email: sdas@appcomsci.com


   John Dowdell
   Airbus Defence and Space
   Celtic Springs
   Newport  NP10 8FZ
   United Kingdom

   Email: john.dowdell.ietf@gmail.com















Mizrahi, et al.        Expires September 14, 2017              [Page 17]


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