| Roll | N. Cam-Winget, Ed. |
| Internet-Draft | Cisco Systems |
| Intended status: Standards Track | J. Hui |
| Expires: April 9, 2017 | Nest |
| D. Popa | |
| Itron, Inc | |
| October 6, 2016 |
Applicability Statement for the Routing Protocol for Low Power and Lossy Networks (RPL) in AMI Networks
draft-ietf-roll-applicability-ami-15
This document discusses the applicability of RPL in Advanced Metering Infrastructure (AMI) networks.
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 April 9, 2017.
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 (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.
Advanced Metering Infrastructure (AMI) systems enable the measurement, configuration, and control of energy, gas and water consumption and distribution, through two-way scheduled, on exception, and on-demand communication.
AMI networks are composed of millions of endpoints, including meters, distribution automation elements, and eventually home area network devices. They are typically inter-connected using some combination of wireless and power-line communications, forming the so-called Neighbor Area Network (NAN) along with a backhaul network providing connectivity to "command-and-control" management software applications at the utility company back office.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
[surveySG] gives an overview of Smart Grid architecture and related applications.
NAN can use wireless communication technology in which case is using, from the IEEE 802.15.4 standard family, the [IEEE802.15.4g] PHY Layer amendment and [IEEE802.15.4e] MAC sub-layer amendment, specifically adapted to smart grid networks.
NAN can also use PLC (Power Line Communication) technology as an alternatve to wireless communications. Several standards for PLC technology have emerged, such as [IEEE1901.2].
NAN can further use a mix of wireless and PLC technologies to increase the network coverage ratio, a critical requirement for AMI networks.
The following are outside the scope of this document:
RPL provides routing functionality for mesh networks that can scale up to thousands of resource-constrained devices, interconnected by low power and lossy links, and communicating with the external network infrastructure through a common aggregation point(s) (e.g., a LLN Border Router or LBR).
RPL builds a Directed Acyclic Graph (DAG) routing structure rooted at a LBR (LLN Border Router), ensures loop-free routing, and provides support for alternate routes, as well as, for a wide range of routing metrics and policies.
RPL was designed to operate in energy-constrained environments and includes energy-saving mechanisms (e.g., Trickle timers) and energy- aware metrics. RPL's ability to support multiple different metrics and constraints at the same time enables it to run efficiently in heterogeneous networks composed of nodes and links with vastly different characteristics [RFC6551].
This document describes the applicability of RPL non-storing mode (as defined in [RFC6550]) to AMI deployments. The Routing Requirements for Urban Low-Power and Lossy Networks are applicable to AMI networks as well. The terminology used in this document is defined in [RFC7102].
In many deployments, in addition to measuring energy consumption, the electric meter network plays a central role in the Smart Grid since the device enables the utility company to control and query the electric meters themselves and can serve as a backhaul for all other devices in the Smart Grid, e.g., water and gas meters, distribution automation and home area network devices. Electric meters may also be used as sensors to monitor electric grid quality and to support applications such as Electric Vehicle charging.
Electric meter networks can be composed of millions of smart meters (or nodes), each of which is resource-constrained in terms of processing power, storage capabilities, and communication bandwidth, due to a combination of factors including regulations on spectrum use, and on meter behavior and performance, on heat emissions within the meter, form factor and cost considerations. These constraints result in a compromise between range and throughput, with effective link throughput of tens to a few hundred kilobits per second per link, a potentially significant portion of which is taken up by protocol and encryption overhead when strong security measures are in place.
Electric meters are often interconnected into multi-hop mesh networks, each of which is connected to a backhaul network leading to the utility company network through a network aggregation point, e.g., an LBR.
AMI networks are composed of millions of endpoints distributed across both urban and rural environments. Such endpoints can include electric, gas, and water meters, distribution automation elements, and home area network devices.
Devices in the network communicate directly with other devices in close proximity using a variety of low-power and/or lossy link technologies that are both wireless and wired (e.g., IEEE 802.15.4g, IEEE 802.15.4e, IEEE 1901.2, IEEE 802.11). In addition to serving as sources and destinations of packets, many network elements typically also forward packets and thus form a mesh topology.
In a typical AMI deployment, groups of meters within physical proximity form routing domains, each in the order of a 1,000 to 10,000 meters. Thus, each electric meter mesh typically has several thousand wireless endpoints, with densities varying based on the area and the terrain.
|
+M
|
M M M M | M
/-----------\ /---+---+---+---+--+-+- phase 1
+----+ ( Internet ) +-----+ / M M M M
|MDMS|---( )----| LBR |/----+----+----+----+---- phase 2
+----+ ( WAN ) +-----+\
\----------/ \ M M M M
\--+--+----+-+---+----- phase 3
\ M M
+--+---+--
<----------------------------->
RPL
Figure 1: Typical NAN Topology
A typical AMI network architecture (see figure Figure 1) is composed of a MDMS (Meter Data Management System) connected through IP network to a LBR, which can be located in the power substation or somewhere else in the field. The power substation connects the households and buildings. The physical topology of the electrical grid is a tree structure, either due to the 3 different power phases coming through the sub-station or just to the electrical network topology. Meters (represented by a M in the previous figure) can also participate in a HAN (Home-Area Network). The scope of this document is the communication between the LBR and the meters, i.e. the NAN (Neighbor-Area Network) segment.
Node density can vary significantly. For example, apartment buildings in urban centers may have hundreds of meters in close proximity, whereas rural areas may have sparse node distributions and include nodes that only have a small number of network neighbors. Each routing domain is connected to the larger IP infrastructure through one or more LBRs, which provide Wide Area Network (WAN) connectivity through various traditional network technologies, e.g., Ethernet, cellular, private WiMAX-based WAN, optical fiber. Paths in the mesh between a network node and the nearest LBR may be composed of several hops or even several tens of hops. Powered from the main line, electric meters have less energy constraints than battery powered devices, such as gas and water meters, and can afford the additional resources required to route packets.
As a function of the technology used to exchange information, the logical network topology will not necessarily match the electric grid topology. If meters exchange information through radio technologies such as in IEEE 802.15.4 family, the topology is a meshed network, where nodes belonging to the same DODAG (Destination Oriented Directed Acyclic Graph ) can be connected to the grid through different substations. If narrowband PLC technology is used, it will follow more or less the physical tree structure since diaphony may allow one phase to communicate with the other. This is particularly true near the LBR. Some mixed topology can also be observed, since some LBRs may be strategically installed in the field to avoid all the communications going through a single LBR. Nethertheless, the short propagation range forces meters to relay the information.
In current AMI deployments, metering applications typically require all smart meters to communicate with a few head-end servers, deployed in the utility company data center. Head-end servers generate data traffic to configure smart data reading or initiate queries, and use unicast and multicast to efficiently communicate with a single device (i.e. Point-to-Point (P2P) communications) or groups of devices respectively (i.e., Point-to-Multipoint (P2MP) communication). The head-end server may send a single small packet at a time to the meters (e.g., a meter read request, a small configuration change, service switch command) or a series of large packets (e.g., a firmware download across one or even thousands of devices). The frequency of large file transfers (e.g., firmware download of all metering devices) is typically much lower than the frequency of sending configuration messages or queries. Each smart meter generates Smart Metering Data (SMD) traffic according to a schedule (e.g., periodic meter reads), in response to on-demand queries (e.g., on-demand meter reads), or in response to some local event (e.g., power outage, leak detection). Such traffic is typically destined to a single head-end server. The SMD traffic is thus highly asymmetric, where the majority of the traffic volume generated by the smart meters typically goes through the LBRs, and is directed from the smart meter devices to the head-end servers, in a MP2P (Mesh Peer to Peer)fashion. Current SMD traffic patterns are fairly uniform and well-understood. The traffic generated by the head-end server and destined to metering devices is dominated by periodic meter reads, while traffic generated by the metering devices is typically uniformly spread over some periodic read time-window.
Smart metering applications typically do not have hard real-time constraints, but they are often subject to bounded latency and stringent reliability service level agreements.
Distribution Automation (DA) applications typically involve a small number of devices that communicate with each other in a Point-to- Point (P2P) fashion, and may or may not be in close physical proximity. DA applications typically have more stringent latency requirements than SMD applications.
There are also a number of emerging applications such as electric vehicle charging. These applications may require P2P communication and may eventually have more stringent latency requirements than SMD applications.
As described previously, the two main traffic families in a NAN are:
The M2HE are event-based, while the HE2M are mostly command-response. In most cases, M2HE traffic is more critical than HE2M one, but there can be exceptions.
Regarding priority, traffic may also be decomposed into several classes :
RPL non-storing mode of operation naturally support upstream and downstream forwarding of unicast traffic between the DODAG root and each DODAG node, and between DODAG nodes and DODAG root, respectively.
Group communication model used in smart grid requires RPL non-storing mode of operation to support downstream forwarding of multicast traffic with a scope larger than link-local. The DODAG root is the single device that injects multicast traffic, with a scope larger than link-local, into the DODAG.
IEEE Std. 802.15.4g and IEEE 802.15.4e amendments to 802.15.4 standard have been specifically developed for smart grid networks. They are the most common PHY and MAC layers used for wireless AMI network. 802.15.4g specifies multiple modes of operation (FSK, OQPSK and OFDM modulations) with speeds from 50kbps to 600kbps, and allows for transport of a full IPv6 packet (i.e., 1280 octets) without the need for upper layer segmentation and re-assembly.
IEEE Std. 802.15.4e is an amendment to IEEE Std 802.15.4 that specifies additional media access control (MAC) behaviors and frame formats that allow IEEE 802.15.4 devices to support a wide range of industrial and commercial applications that were not adequately supported prior to the release of this amendment. It is important to notice that 802.15.4e does not change the link-layer security scheme defined in the last two updates to 802.15.4 (e.g. 2006 and 2011 amendments).
The IEEE Std. 1901.2 standard specifies communications for low frequency (less than 500 kHz) narrowband power line devices via alternating current and direct current electric power lines. IEEE Std P1901.2 standard supports indoor and outdoor communications over low voltage line (line between transformer and meter, less than 1000 V), through transformer low-voltage to medium-voltage (1000 V up to 72 kV) and through transformer medium-voltage to low-voltage power lines in both urban and in long distance (multi- kilometer) rural communications.
IEEE Std. 1901.2 defines the PHY layer and the MAC sub-layer of the data link layer. The MAC sub-layer endorses a sub-set of 802.15.4 and 802.15.4e MAC sub-layer features.
IEEE Std. 1901.2 PHY Layer bit rates are scalable up to 500 kbps depending on the application requirements and type of encoding used.
IEEE Std. 1901.2 MAC layer allows for transport of a full IPv6 packet (i.e., 1280 octets) without the need for upper layer segmentation and re-assembly.
IEEE Std. 1901.2 specifies the necessary link-layer security features that fully endorse 802.15.4 MAC sub-layer security scheme.
The functional requirements for most AMI deployments are similar to those listed in [RFC5548]. This section informallly highlights some of the similarities:
RPL supports the following features:
RPL operation is defined for a single RPL instance. However, multiple RPL instances can be supported in multi-service networks where different applications may require the use of different routing metrics and constraints, e.g., a network carrying both SDM and DA traffic.
Two-way communication is a requirement in AMI systems. As a result, nodes SHOULD send DAO messages to establish downward paths from the root to themselves.
Smart metering deployments utilize link technologies that may exhibit significant packet loss and thus require routing metrics that take packet loss into account. To characterize a path over such link technologies, AMI deployments can use the Expected Transmission Count (ETX) metric as defined in [RFC6551].
Additional metrics may be defined in companion RFCs.
RPL relies on an Objective Function for selecting parents and computing path costs and rank. This objective function is decoupled from the core RPL mechanisms and also from the metrics in use in the network. Two objective functions for RPL have been defined at the time of this writing, OF0 [RFC6552] and MRHOF [RFC6719], both of which define the selection of a preferred parent and backup parents, and are suitable for AMI deployments.
Additional objective functions may be defined in companion RFCs.
To effectively handle time-varying link characteristics and availability, AMI deployments SHOULD utilize the local repair mechanisms in RPL. Local repair is triggered by broken link detection. The first local repair mechanism consists of a node detaching from a DODAG and then re-attaching to the same or to a different DODAG at a later time. While detached, a node advertises an infinite rank value so that its children can select a different parent. This process is known as poisoning and is described in Section 8.2.2.5 of [RFC6550]. While RPL provides an option to form a local DODAG, doing so in AMI for electric meters is of little benefit since AMI applications typically communicate through a LBR. After the detached node has made sufficient effort to send notification to its children that it is detached, the node can rejoin the same DODAG with a higher rank value. The configured duration of the poisoning mechanism needs to take into account the disconnection time applications running over the network can tolerate. Note that when joining a different DODAG, the node need not perform poisoning. The second local repair mechanism controls how much a node can increase its rank within a given DODAG Version (e.g., after detaching from the DODAG as a result of broken link or loop detection). Setting the DAGMaxRankIncrease to a non-zero value enables this mechanism, and setting it to a value of less than infinity limits the cost of count-to-infinity scenarios when they occur, thus controlling the duration of disconnection applications may experience.
Multicast support for RPL in non-storing mode are being developed in companion RFCs (see [RFC7731]).
AMI deployments operate in areas that do not provide any physical security. For this reason, the link layer, transport layer and application layer technologies utilized within AMI networks typically provide security mechanisms to ensure authentication, confidentiality, integrity, and freshness. As a result, AMI deployments may not need to implement RPL's security mechanisms; they MUST include, at a minimum, link layer security such as that defined by IEEE 1901.2 and IEEE 802.15.4.
The IEEE Std. 1901.2 PHY layer is based on OFDM modulation and defines a time frequency interleaver over the entire PHY frame coupled with a Reed Solomon and Viterbi Forward Error Correction for maximum robustness. Since the noise level in each OFDM sub-carrier can vary significantly, IEEE 1901.2 specifies two complementary mechanisms allowing to fine-tune the robustness/performance tradeoff implicit in such systems. More specifically, the first (coarse-grained) mechanism, defines the modulation from several possible choices (robust (super-ROBO, ROBO), BPSK, QPSK,...). The second (fine-grained) maps the sub-carriers which are too noisy and deactivates them.
The existence of multiple modulations and dynamic frequency exclusion renders the problem of selecting a path between two nodes non-trivial, as the possible number of combinations increases significantly, e.g. use a direct link with slow robust modulation, or use a relay meter with fast modulation and 12 disabled sub-carriers. In addition, IEEE 1901.2 technology offers a mechanism (adaptive tone map) for periodic exchanges on the link quality between nodes to constantly react to channel fluctuations. Every meter keeps a state of the quality of the link to each of its neighbors by either piggybacking the tone mapping on the data traffic, or by sending explicit tone map requests.
IEEE 1901.2 MAC frame format shares most in common with the IEEE 802.15.4 MAC frame format [IEEE802.15.4], with a few exceptions described below.
The IEEE 1901.2 PHY frame payload size varies as a function of the modulation used to transmit the frame and the strength of the Forward Error Correction scheme.
The IEEE 1901.2 PHY MTU size is variable and dependent on the PHY settings in use (e.g. bandwidth, modulation, tones, etc). As quoted from the IEEE 1901.2 specification: For CENELEC A/B, if MSDU size is more than 247 octets for robust OFDM (ROBO) and Super-ROBO modulations or more than 239 octets for all other modulations, the MAC layer shall divide the MSDU into multiple segments as described in 5.3.7. For FCC and ARIB, if the MSDU size meets one of the following conditions: a) For ROBO and Super-ROBO modulations, the MSDU size is more than 247 octets but less than 494 octets, b) For all other modulations, the MSDU size is more than 239 octets but less than 478 octets.
IEEE Std 802.15.4g defines multiple modes of operation, where each mode uses different modulation and has multiple data rates. Additionally, 802.15.4g PHY layer includes mechanisms to improve the robustness of the radio communications, such as data whitening and Forward Error Correction coding. The 802.15.4g PHY frame payload can carry up to 2048 octets.
The IEEE Std 802.15.4g defines the following modulations: MR-FSK (Multi- Rate FSK), MR-OFDM (Multi-Rate OFDM) and MR-O-QPSK (Multi- Rate O-QPSK). The (over-the-air) bit rates for these modulations range from 4.8 to 600kbps for MR-FSK, from 50 to 600kbps for MR-OFDM and from 6.25 to 500kbps for MR-O-QPSK.
The MAC sub-layer running on top of a 4g radio link is based on IEEE 802.15.4e. The 802.15.4e MAC allows for a variety of modes for operation. These include:
The MAC addressing scheme supports short (16-bits) addresses along with extended (64-bits) addresses. These addresses are assigned in different ways and is specified by specific standards organizations.
Information Elements, Enhanced Beacons and frame version 2, as defined in 802.15.4e, MUST be supported.
Since the MAC frame payload size limitation is given by the 4g PHY frame payload size limitation (i.e.,2048 bytes) and MAC layer overhead (headers, trailers, Information Elements and security overhead), the MAC frame payload MUST able to carry a full IPv6 packet of 1280 octets without upper layer fragmentation and re- assembly.
Since IEEE 1901.2 standard is based on the 802.15.4 MAC sub-layer and fully endorses the security scheme defined in 802.15.4, we only focus on description of IEEE 802.15.4 security scheme.
The IEEE 802.15.4 specification was designed to support a variety of applications, many of which are security sensitive. The IEEE 802.15.4 provides four basic security services: message authentication, message integrity, message confidentiality, and freshness checks to avoid replay attacks.
The 802.15.4 security layer is handled at the media access control layer, below 6LowPAN layer. The application specifies its security requirements by setting the appropriate control parameters into the radio/PLC stack. The 802.15.4 defines four packet types: beacon frames, data frames, acknowledgments frame, and command frames for the media access control layer. The 802.15.4 specification does not support security for acknowledgement frames; data frames, beacon frames and command frames can support integrity protection and confidentiality protection for the frames's data field. An application has a choice of security suites that control the type of security protection that is provided for the transmitted MAC frame. Each security suite offers a different set of security properties and guarantees, and ultimately different MAC frame formats. The 802.15.4 specification defines eight different security suites, outlined bellow. We can broadly classify the suites by the properties that they offer: no security, encryption only (AES-CTR), authentication only (AES-CBC-MAC), and encryption and authentication (AES-CCM). Each category that supports authentication comes in three variants depending on the size of the MAC (Message Authentication Control) that it offers. The MAC can be either 4, 8, or 16 bytes long. Additionally, for each suite that offers encryption, the recipient can optionally enable replay protection.
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.
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.
Trickle [RFC6206] 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 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.
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.
Smart grid networks are subject to stringent security requirements as they are considered a critical infrastructure component. At the same time, they are composed of large numbers of resource- constrained devices inter-connected with limited-throughput links. 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.
During the manufacturing process, the meters are loaded with the appropriate security credentials (keys, certificates). The configured security credentials during manufacturing are used by the devices to authenticate with the system and to further negotiate operational security credentials, for both network and application layers.
If during the system operation a device fails or is known to be 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.
[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.
Privacy of information flowing through smart grid networks are subject to consideration. An evolving a set of recommendations and requirements are deing defined by different groups and consortiums; for example, the U.S. Department of Energy issued a document [DOEVCC] defining a process and set of recommendations to address privacy issues. As this document describes the applicability of RPL, the privacy considerations as defined in [I-D.ietf-6lo-privacy-considerations] and [EUPR] apply to this document and to AMI deployments.
This memo includes no request to IANA.
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.