Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks
draft-ietf-roll-applicability-ami-13

o  AES-CCM-64 = Encryption and 64-bit MAC.

   o  AES-CCM-32 = Encryption and 32-bit MAC.

   Note that AES-CCM-32 is the most commonly used cipher in these
   deployments today.

   To achieve authentication, any device can maintain an Access Control
   List (ACL) which is a list of trusted nodes from which the device
   wishes to receive data.  Data encryption is done by encryption of
   Message Authentication Control (MAC) frame payload using the key
   shared between two devices, or among a group of peers.  If the key is
   to be shared between two peers, it is stored with each entry in the
   ACL list; otherwise, the key is stored as the default key.  Thus, the
   device can make sure that its data can not be read by devices that do
   not possess the corresponding key.  However, device addresses are
   always transmitted unencrypted, which makes attacks that rely on
   device identity somewhat easier to launch.  Integrity service is
   applied by appending a Message Integrity Code (MIC) generated from
   blocks of encrypted message text.  This ensures that a frame can not
   be modified by a receiver device that does not share a key with the
   sender.  Finally, sequential freshness uses a frame counter and key
   sequence counter to ensure the freshness of the incoming frame and
   guard against replay attacks.

   A cryptographic MAC is used to authenticate messages.  While longer
   MACs lead to improved resiliency of the code, they also make packet
   size larger and thus take up bandwidth in the network.  In
   constrained environments such as metering infrastructures, an optimum
   balance between security requirements and network throughput must be
   found.

7.3.  6LowPAN Options

   AMI implementations based on 1901.2 and 802.15.4(g+e) can utilize all
   of the IPv6 Header Compression schemes specified in [RFC6282]
   Section 3 and all of the IPv6 Next Header compression schemes
   specified in [RFC6282] Section 4, if reducing over the air/wire
   overhead is a requirement.

7.4.  Recommended Configuration Defaults and Ranges

7.4.1.  Trickle Parameters

   Trickle was designed to be density-aware and perform well in networks
   characterized by a wide range of node densities.  The combination of
   DIO packet suppression and adaptive timers for sending updates allows
   Trickle to perform well in both sparse and dense environments.  Node

Cam-Winget, et al.      Expires October 27, 2016               [Page 16]
Internet-Draft          RPL Applicability for AMI             April 2016

   densities in AMI deployments can vary greatly, from nodes having only
   one or a handful of neighbors to nodes having several hundred
   neighbors.  In high density environments, relatively low values for
   Imin may cause a short period of congestion when an inconsistency is
   detected and DIO updates are sent by a large number of neighboring
   nodes nearly simultaneously.  While the Trickle timer will
   exponentially backoff, some time may elapse before the congestion
   subsides.  While some link layers employ contention mechanisms that
   attempt to avoid congestion, relying solely on the link layer to
   avoid congestion caused by a large number of DIO updates can result
   in increased communication latency for other control and data traffic
   in the network.  To mitigate this kind of short-term congestion, this
   document recommends a more conservative set of values for the Trickle
   parameters than those specified in [RFC6206].  In particular,
   DIOIntervalMin is set to a larger value to avoid periods of
   congestion in dense environments, and DIORedundancyConstant is
   parameterized accordingly as described below.  These values are
   appropriate for the timely distribution of DIO updates in both sparse
   and dense scenarios while avoiding the short-term congestion that
   might arise in dense scenarios.  Because the actual link capacity
   depends on the particular link technology used within an AMI
   deployment, the Trickle parameters are specified in terms of the
   link's maximum capacity for transmitting link-local multicast
   messages.  If the link can transmit m link-local multicast packets
   per second on average, the expected time it takes to transmit a link-
   local multicast packet is 1/m seconds.

   DIOIntervalMin:  AMI deployments SHOULD set DIOIntervalMin such that
      the Trickle Imin is at least 50 times as long as it takes to
      transmit a link-local multicast packet.  This value is larger than
      that recommended in [RFC6206] to avoid congestion in dense urban
      deployments as described above.

   DIOIntervalDoublings:  AMI deployments SHOULD set
      DIOIntervalDoublings such that the Trickle Imax is at least 2
      hours or more.

   DIORedundancyConstant:  AMI deployments SHOULD set
      DIORedundancyConstant to a value of at least 10.  This is due to
      the larger chosen value for DIOIntervalMin and the proportional
      relationship between Imin and k suggested in [RFC6206].  This
      increase is intended to compensate for the increased communication
      latency of DIO updates caused by the increase in the
      DIOIntervalMin value, though the proportional relationship between
      Imin and k suggested in [RFC6206] is not preserved.  Instead,
      DIORedundancyConstant is set to a lower value in order to reduce
      the number of packet transmissions in dense environments.

Cam-Winget, et al.      Expires October 27, 2016               [Page 17]
Internet-Draft          RPL Applicability for AMI             April 2016

7.4.2.  Other Parameters

   o  AMI deployments SHOULD set MinHopRankIncrease to 256, resulting in
      8 bits of resolution (e.g., for the ETX metric).

   o  To enable local repair, AMI deployments SHOULD set MaxRankIncrease
      to a value that allows a device to move a small number of hops
      away from the root.  With a MinHopRankIncrease of 256, a
      MaxRankIncrease of 1024 would allow a device to move up to 4 hops
      away.

8.  Manageability Considerations

   Network manageability is a critical aspect of smart grid network
   deployment and operation.  With millions of devices participating in
   the smart grid network, many requiring real-time reachability,
   automatic configuration, and lightweight network health monitoring
   and management are crucial for achieving network availability and
   efficient operation.  RPL enables automatic and consistent
   configuration of RPL routers through parameters specified by the
   DODAG root and disseminated through DIO packets.  The use of Trickle
   for scheduling DIO transmissions ensures lightweight yet timely
   propagation of important network and parameter updates and allows
   network operators to choose the trade-off point they are comfortable
   with respect to overhead vs.  reliability and timeliness of network
   updates.  The metrics in use in the network along with the Trickle
   Timer parameters used to control the frequency and redundancy of
   network updates can be dynamically varied by the root during the
   lifetime of the network.  To that end, all DIO messages SHOULD
   contain a Metric Container option for disseminating the metrics and
   metric values used for DODAG setup.  In addition, DIO messages SHOULD
   contain a DODAG Configuration option for disseminating the Trickle
   Timer parameters throughout the network.  The possibility of
   dynamically updating the metrics in use in the network as well as the
   frequency of network updates allows deployment characteristics (e.g.,
   network density) to be discovered during network bring-up and to be
   used to tailor network parameters once the network is operational
   rather than having to rely on precise pre- configuration.  This also
   allows the network parameters and the overall routing protocol
   behavior to evolve during the lifetime of the network.  RPL specifies
   a number of variables and events that can be tracked for purposes of
   network fault and performance monitoring of RPL routers.  Depending
   on the memory and processing capabilities of each smart grid device,
   various subsets of these can be employed in the field.

Cam-Winget, et al.      Expires October 27, 2016               [Page 18]
Internet-Draft          RPL Applicability for AMI             April 2016

9.  Security Considerations

   Smart grid networks are subject to stringent security requirements as
   they are considered a critical infrastructure component.  At the same
   time, since they are composed of large numbers of resource-
   constrained devices inter-connected with limited-throughput links,
   many available security mechanisms are not practical for use in such
   networks.  As a result, the choice of security mechanisms is highly
   dependent on the device and network capabilities characterizing a
   particular deployment.

   In contrast to other types of LLNs, in smart grid networks
   centralized administrative control and access to a permanent secure
   infrastructure is available.  As a result, smart grid networks are
   deployed with security mechanisms such as link-layer, transport layer
   and/or application-layer security mechanisms; while it is best
   practice to secure all layers, using RPL's secure mode may not be
   necessary.  Failure to protect any of these layers can result in
   various attacks; without strong authentication of devices in the
   infrastructure can lead to uncontrolled and unauthorized access.
   Similarly, failure to protect the communication layers can enable
   passive (in wireless mediums) attacks as well as man-in-the-middle
   and active attacks.

   As this document describes the applicability of RPL non-storing mode,
   the security considerations as defined in [RFC6550] also applies to
   this document and to AMI deployments.

9.1.  Security Considerations during initial deployment

   During the manufacturing process, the meters are loaded with the
   appropriate security credentials (keys, certificates).  These
   security credentials are unique per device and only known by the
   device itself and the head-end security appliances.  The
   manufacturing security credentials are then used by the devices to
   authenticate with the system and negotiate operational security
   credentials, for both network and application layers.

9.2.  Security Considerations during incremental deployment

   If during the system operation a device fails or is compromised, it
   is replaced with a new device.  The new device does not take over the
   security identity of the replaced device.  The security credentials
   associated with the failed/compromised device are removed from the
   security appliances.

Cam-Winget, et al.      Expires October 27, 2016               [Page 19]
Internet-Draft          RPL Applicability for AMI             April 2016

9.3.  Security Considerations based on RPL's Threat Analysis

   [RFC7416] defines a set of security considerations for RPL security.
   This document defines how it leverages the device's link layer and
   application layer security mechanisms to address the threats as
   defined in Section 6 of [RFC7416].

   Like any secure network infrastructure, an AMI deployment's ability
   to address node impersonation, active man-in-the-middle attacks
   relies on mutual authentication and authorization process.  The
   credential management from the manufacturing imprint of security
   credentials of smart meters to all credentials of nodes in the
   infrastructure, all credentials must be appropriately managed and
   classified through the authorization process to ensure beyond the
   identity of the nodes, that the nodes are behaving or 'acting' in
   their assigned roles.

   Similarly, to ensure that data has not been modified, confidentiality
   and integrity at the suitable layers (e.g. link layer, application
   layer or both) should be used.

   To provide the security mechanisms to address these threats, an AMI
   deployment MUST include the use of the security schemes as defined by
   IEEE 1901.2 (and IEEE 802.15.4).  With IEEE 802.15.4 defining the
   security mechanisms to afford mutual authentication, access control
   (e.g. authorization) and transport confidentiality and integrity.
   The credential management is afforded through the use of already
   existing identity management solutions.

10.  IANA Considerations

   This memo includes no request to IANA.

11.  Acknowledgements

   Matthew Gillmore, Laurent Toutain, Ruben Salazar, and Kazuya Monden
   were contributors and noted as authors in earlier drafts.  The
   authors would also like to acknowledge the review, feedback, and
   comments of Jari Arkko, Dominique Barthel, Cedric Chauvenet, Yuichi
   Igarashi, Philip Levis, Jeorjeta Jetcheva, Nicolas Dejean, and JP
   Vasseur.

12.  References

Cam-Winget, et al.      Expires October 27, 2016               [Page 20]
Internet-Draft          RPL Applicability for AMI             April 2016

12.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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <http://www.rfc-editor.org/info/rfc6550>.

   [IEEE802.15.4]
              "IEEE Standard for Information technology-- Local and
              metropolitan area networks-- Specific requirements-- Part
              15.4: Wireless Medium Access Control (MAC) and Physical
              Layer (PHY) Specifications for Low Rate Wireless Personal
              Area Networks (WPANs)", IEEE Standard 802.15.4, September
              2006.

   [IEEE802.15.4e]
              "IEEE Standard for Local and metropolitan area networks--
              Part 15.4: Low-Rate Wireless Personal Area Networks (LR-
              WPANs) Amendment 1: MAC sublayer", IEEE Standard
              802.15.4e, April 2012.

   [IEEE802.15.4g]
              "IEEE Standard for Local and metropolitan area networks--
              Part 15.4: Low-Rate Wireless Personal Area Networks (LR-
              WPANs) Amendment 3: Physical Layer (PHY) Specifications
              for Low-Data-Rate, Wireless, Smart Metering Utility
              Networks", IEEE Standard 802.15.4g, November 2012.

   [IEEE1901.2]
              "IEEE Standard for Low-Frequency (less than 500 kHz)
              Narrowband Power Line Communications for Smart Grid
              Applications", IEEE Standard 1901.2, December 2013.

12.2.  Informative references

   [RFC5673]  Pister, K., Ed., Thubert, P., Ed., Dwars, S., and T.
              Phinney, "Industrial Routing Requirements in Low-Power and
              Lossy Networks", RFC 5673, DOI 10.17487/RFC5673, October
              2009, <http://www.rfc-editor.org/info/rfc5673>.

Cam-Winget, et al.      Expires October 27, 2016               [Page 21]
Internet-Draft          RPL Applicability for AMI             April 2016

   [RFC5867]  Martocci, J., Ed., De Mil, P., Riou, N., and W. Vermeylen,
              "Building Automation Routing Requirements in Low-Power and
              Lossy Networks", RFC 5867, DOI 10.17487/RFC5867, June
              2010, <http://www.rfc-editor.org/info/rfc5867>.

   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low-Power and Lossy Networks",
              RFC 5826, DOI 10.17487/RFC5826, April 2010,
              <http://www.rfc-editor.org/info/rfc5826>.

   [RFC7102]  Vasseur, JP., "Terms Used in Routing for Low-Power and
              Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
              2014, <http://www.rfc-editor.org/info/rfc7102>.

   [RFC6997]  Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
              J. Martocci, "Reactive Discovery of Point-to-Point Routes
              in Low-Power and Lossy Networks", RFC 6997,
              DOI 10.17487/RFC6997, August 2013,
              <http://www.rfc-editor.org/info/rfc6997>.

   [RFC7731]  Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power
              and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731,
              February 2016, <http://www.rfc-editor.org/info/rfc7731>.

   [surveySG]
              Gungor, V., Sahin, D., Kocak, T., Ergut, S., Buccella, C.,
              Cecati, C., and G. Hancke, "A Survey on Smart Grid
              Potential Applications and Communication Requirements",
              Feb 2013.

   [RFC5548]  Dohler, M., Ed., Watteyne, T., Ed., Winter, T., Ed., and
              D. Barthel, Ed., "Routing Requirements for Urban Low-Power
              and Lossy Networks", RFC 5548, DOI 10.17487/RFC5548, May
              2009, <http://www.rfc-editor.org/info/rfc5548>.

   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
              "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
              March 2011, <http://www.rfc-editor.org/info/rfc6206>.

   [RFC6551]  Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
              and D. Barthel, "Routing Metrics Used for Path Calculation
              in Low-Power and Lossy Networks", RFC 6551,
              DOI 10.17487/RFC6551, March 2012,
              <http://www.rfc-editor.org/info/rfc6551>.

Cam-Winget, et al.      Expires October 27, 2016               [Page 22]
Internet-Draft          RPL Applicability for AMI             April 2016

   [RFC6719]  Gnawali, O. and P. Levis, "The Minimum Rank with
              Hysteresis Objective Function", RFC 6719,
              DOI 10.17487/RFC6719, September 2012,
              <http://www.rfc-editor.org/info/rfc6719>.

   [RFC6552]  Thubert, P., Ed., "Objective Function Zero for the Routing
              Protocol for Low-Power and Lossy Networks (RPL)",
              RFC 6552, DOI 10.17487/RFC6552, March 2012,
              <http://www.rfc-editor.org/info/rfc6552>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <http://www.rfc-editor.org/info/rfc6282>.

   [RFC7416]  Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
              and M. Richardson, Ed., "A Security Threat Analysis for
              the Routing Protocol for Low-Power and Lossy Networks
              (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
              <http://www.rfc-editor.org/info/rfc7416>.

Authors' Addresses

   Nancy Cam-Winget (editor)
   Cisco Systems
   3550 Cisco Way
   San Jose, CA  95134
   US

   Email: ncamwing@cisco.com

   Jonathan Hui
   Nest
   3400 Hillview Ave
   Palo Alto, CA  94304
   USA

   Email: jonhui@nestlabs.com

   Daniel Popa
   Itron, Inc
   52, rue Camille Desmoulins
   Issy les Moulineaux  92130
   FR

   Email: daniel.popa@itron.com

Cam-Winget, et al.      Expires October 27, 2016               [Page 23]