RFC 6272
Internet Protocols for the Smart Grid
Pages: 66
Informational
Informational
Part 1 of 4 – Pages 1 to 14
Internet Engineering Task Force (IETF) F. Baker Request for Comments: 6272 D. Meyer Category: Informational Cisco Systems ISSN: 2070-1721 June 2011 Internet Protocols for the Smart GridAbstract
This note identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6272. Copyright Notice Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 6 2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 6 2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 7 2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . 9 2.1.3.2. Lower-Layer Networks . . . . . . . . . . . . . . . 9 2.1.4. Media Layers: Physical and Link . . . . . . . . . . . 9 2.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. Physical and Data Link Layer Security . . . . . . . . 10 2.2.2. Network, Transport, and Application Layer Security . . 11 2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 13 2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 13 2.3.2. Network Management . . . . . . . . . . . . . . . . . . 13 3. Specific Protocols . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Security Toolbox . . . . . . . . . . . . . . . . . . . . . 14 3.1.1. Authentication, Authorization, and Accounting (AAA) . 14 3.1.2. Network Layer Security . . . . . . . . . . . . . . . . 15 3.1.3. Transport Layer Security . . . . . . . . . . . . . . . 16 3.1.4. Application Layer Security . . . . . . . . . . . . . . 17 3.1.5. Secure Shell . . . . . . . . . . . . . . . . . . . . . 18 3.1.6. Key Management Infrastructures . . . . . . . . . . . . 18 3.1.6.1. PKIX . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.6.2. Kerberos . . . . . . . . . . . . . . . . . . . . . 19 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 19 3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 19 3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . . . . 19 3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . 20 3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . 20 3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . 21 3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . 22 3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 22 3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . 22 3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . 23 3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . 23 3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 24 3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . 24 3.2.4.1. Routing Information Protocol . . . . . . . . . . . 24 3.2.4.2. Open Shortest Path First . . . . . . . . . . . . . 24 3.2.4.3. ISO Intermediate System to Intermediate System . . 25 3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . 25 3.2.4.5. Dynamic MANET On-Demand (DYMO) Routing . . . . . . 25 3.2.4.6. Optimized Link State Routing Protocol . . . . . . 26 3.2.4.7. Routing for Low-Power and Lossy Networks . . . . . 26
3.2.5. IPv6 Multicast Forwarding and Routing . . . . . . . . 27
3.2.5.1. Protocol-Independent Multicast Routing . . . . . . 27
3.2.6. Adaptation to Lower-Layer Networks and Link Layer
Protocols . . . . . . . . . . . . . . . . . . . . . . 28
3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 28
3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 28
3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 29
3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 29
3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 30
3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 30
3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 31
3.4.3. Network Time . . . . . . . . . . . . . . . . . . . . . 31
3.5. Network Management . . . . . . . . . . . . . . . . . . . . 31
3.5.1. Simple Network Management Protocol (SNMP) . . . . . . 31
3.5.2. Network Configuration (NETCONF) Protocol . . . . . . . 32
3.6. Service and Resource Discovery . . . . . . . . . . . . . . 33
3.6.1. Service Discovery . . . . . . . . . . . . . . . . . . 33
3.6.2. Resource Discovery . . . . . . . . . . . . . . . . . . 33
3.7. Other Applications . . . . . . . . . . . . . . . . . . . . 34
3.7.1. Session Initiation Protocol . . . . . . . . . . . . . 34
3.7.2. Extensible Messaging and Presence Protocol . . . . . . 35
3.7.3. Calendaring . . . . . . . . . . . . . . . . . . . . . 35
4. A Simplified View of the Business Architecture . . . . . . . . 35
5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. Normative References . . . . . . . . . . . . . . . . . . . 40
7.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Example: Advanced Metering Infrastructure . . . . . . 58
A.1. How to Structure a Network . . . . . . . . . . . . . . . . 59
A.1.1. HAN Routing . . . . . . . . . . . . . . . . . . . . . 62
A.1.2. HAN Security . . . . . . . . . . . . . . . . . . . . . 62
A.2. Model 1: AMI with Separated Domains . . . . . . . . . . . 64
A.3. Model 2: AMI with Neighborhood Access to the Home . . . . 65
A.4. Model 3: Collector Is an IP Router . . . . . . . . . . . . 66
1. Introduction
This document provides Smart Grid designers with advice on how to best "profile" the Internet Protocol Suite (IPS) for use in Smart Grids. It provides an overview of the IPS and the key infrastructure protocols that are critical in integrating Smart Grid devices into an IP-based infrastructure. In the words of Wikipedia [SmartGrid]: A Smart Grid is a form of electricity network utilizing digital technology. A Smart Grid delivers electricity from suppliers to consumers using two-way digital communications to control appliances at consumers' homes; this saves energy, reduces costs and increases reliability and transparency. It overlays the ordinary electrical Grid with an information and net metering system, that includes smart meters. Smart Grids are being promoted by many governments as a way of addressing energy independence, global warming and emergency resilience issues. A Smart Grid is made possible by applying sensing, measurement and control devices with two-way communications to electricity production, transmission, distribution and consumption parts of the power Grid that communicate information about Grid condition to system users, operators and automated devices, making it possible to dynamically respond to changes in Grid condition. A Smart Grid includes an intelligent monitoring system that keeps track of all electricity flowing in the system. It also has the capability of integrating renewable electricity such as solar and wind. When power is least expensive the user can allow the smart Grid to turn on selected home appliances such as washing machines or factory processes that can run at arbitrary hours. At peak times it could turn off selected appliances to reduce demand. Other names for a Smart Grid (or for similar proposals) include smart electric or power Grid, intelligent Grid (or intelliGrid), futureGrid, and the more modern interGrid and intraGrid. That description focuses on the implications of Smart Grid technology in the home of a consumer. In fact, data communications technologies of various kinds are used throughout the Grid, to monitor and maintain power generation, transmission, and distribution, as well as the operations and management of the Grid. One can view the Smart Grid as a collection of interconnected computer networks that connects and serves the needs of public and private electrical utilities and their customers.
At the time of this writing, there is no single document that can be described as comprising an internationally agreed standard for the Smart Grid; that is in part the issue being addressed in its development. The nearest approximations are probably the Smart Grid Interoperability Panel's Conceptual Model [Model] and documents comprising [IEC61850]. The Internet Protocol Suite (IPS) provides options for numerous architectural components. For example, the IPS provides several choices for the traditional transport function between two systems: the Transmission Control Protocol (TCP) [RFC0793], the Stream Control Transmission Protocol (SCTP) [RFC4960], and the Datagram Congestion Control Protocol (DCCP) [RFC4340]. Another option is to select an encapsulation such as the User Datagram Protocol (UDP) [RFC0768], which essentially allows an application to implement its own transport service. In practice, a designer will pick a transport protocol that is appropriate to the problem being solved. The IPS is standardized by the Internet Engineering Task Force (IETF). IETF protocols are documented in the Request for Comments (RFC) series. Several RFCs have been written describing how the IPS should be implemented. These include: o Requirements for Internet Hosts - Communication Layers [RFC1122], o Requirements for Internet Hosts - Application and Support [RFC1123], o Requirements for IP Version 4 Routers [RFC1812], and o IPv6 Node Requirements [RFC4294]. At the time of this writing, RFC 4294 is in the process of being updated, in [IPv6-NODE-REQ]. This document is intended to provide Smart Grid architects and designers with a compendium of relevant RFCs (and to some extent, Internet Drafts), and is organized as an annotated list of RFCs. To that end, the remainder of this document is organized as follows: o Section 2 describes the Internet Architecture and its protocol suite. o Section 3 outlines a set of protocols that may be useful in Smart Grid deployment. It is not exhaustive. o Finally, Section 4 provides an overview of the business architecture embodied in the design and deployment of the IPS.
2. The Internet Protocol Suite
Before enumerating the list of Internet protocols relevant to Smart Grid, we discuss the layered architecture of the IPS, the functions of the various layers, and their associated protocols.2.1. Internet Protocol Layers
While Internet architecture uses the definitions and language similar to language used by the ISO Open System Interconnect (ISO-OSI) reference model (Figure 1), it actually predates that model. As a result, there is some skew in terminology. For example, the ISO-OSI model uses "end system" while the Internet architecture uses "host". Similarly, an "intermediate system" in the ISO-OSI model is called an "internet gateway" or "router" in Internet parlance. Notwithstanding these differences, the fundamental concepts are largely the same. +--------------------+ | Application Layer | +--------------------+ | Presentation Layer | +--------------------+ | Session Layer | +--------------------+ | Transport Layer | +--------------------+ | Network Layer | +--------------------+ | Data Link Layer | +--------------------+ | Physical Layer | +--------------------+ Figure 1: The ISO OSI Reference Model The structure of the Internet reference model is shown in Figure 2.
+---------------------------------+ |Application | | +---------------------------+ | | | Application Protocol | | | +----------+----------------+ | | | Encoding | Session Control| | | +----------+----------------+ | +---------------------------------+ |Transport | | +---------------------------+ | | | Transport Layer | | | +---------------------------+ | +---------------------------------+ |Network | | +---------------------------+ | | | Internet Protocol | | | +---------------------------+ | | | Lower Network Layers | | | +---------------------------+ | +---------------------------------+ |Media Layers | | +---------------------------+ | | | Data Link Layer | | | +---------------------------+ | | | Physical Layer | | | +---------------------------+ | +---------------------------------+ Figure 2: The Internet Reference Model2.1.1. Application
In the Internet model, the Application, Presentation, and Session layers are compressed into a single entity called "the application". For example, the Simple Network Management Protocol (SNMP) [RFC3411] describes an application that encodes its data in an ASN.1 profile and engages in a session to manage a network element. The point here is that in the Internet, the distinction between these layers exists but is not highlighted. Further, note that in Figure 2, these functions are not necessarily cleanly layered: the fact that an application protocol encodes its data in some way and that it manages sessions in some way doesn't imply a hierarchy between those processes. Rather, the application views encoding, session management, and a variety of other services as a tool set that it uses while doing its work.
2.1.2. Transport
The term "transport" is perhaps among the most confusing concepts in the communication architecture, to a large extent because people with various backgrounds use it to refer to "the layer below that which I am interested in, which gets my data to my peer". For example, optical network engineers refer to optical fiber and associated electronics as "the transport", while web designers refer to the Hypertext Transfer Protocol (HTTP) [RFC2616] (an application layer protocol) as "the transport". In the Internet protocol stack, the "transport" is the lowest protocol layer that travels end-to-end unmodified, and it is responsible for end-to-end data delivery services. In the Internet, the transport layer is the layer above the network layer. Transport layer protocols have a single minimum requirement: the ability to multiplex several applications on one IP address. UDP [RFC0768], TCP [RFC0793], DCCP [RFC4340], SCTP [RFC4960], and NORM [RFC5740] each accomplish this using a pair of port numbers, one for the sender and one for the receiver. A port number identifies an application instance, which might be a general "listener" that peers or clients may open sessions with, or a specific correspondent with such a "listener". The session identification in an IP datagram is often called the "five-tuple", and consists of the source and destination IP addresses, the source and destination ports, and an identifier for the transport protocol in use. In addition, the responsibilities of a specific transport layer protocol typically include the delivery of data (either as a stream of messages or a stream of bytes) in a stated sequence with stated expectations regarding delivery rate and loss. For example, TCP will reduce its rate in response to loss, as a congestion control trigger, while DCCP accepts some level of loss if necessary to maintain timeliness.2.1.3. Network
The main function of the network layer is to identify a remote destination and deliver data to it. In connection-oriented networks such as Multi-protocol Label Switching (MPLS) [RFC3031] or Asynchronous Transfer Mode (ATM), a path is set up once, and data is delivered through it. In connectionless networks such as Ethernet and IP, data is delivered as datagrams. Each datagram contains both the source and destination network layer addresses, and the network is responsible for delivering it. In the Internet Protocol Suite, the Internet Protocol is the network that runs end to end. It may be encapsulated over other LAN and WAN technologies, including both IP networks and networks of other types.
2.1.3.1. Internet Protocol
IPv4 and IPv6, each of which is called the Internet Protocol, are connectionless ("datagram") architectures. They are designed as common elements that interconnect network elements across a network of lower-layer networks. In addition to the basic service of identifying a datagram's source and destination, they offer services to fragment and reassemble datagrams when necessary, assist in diagnosis of network failures, and carry additional information necessary in special cases. The Internet layer provides a uniform network abstraction network that hides the differences between various network technologies. This is the layer that allows diverse networks such as Ethernet, 802.15.4, etc. to be combined into a uniform IP network. New network technologies can be introduced into the IP Protocol Suite by defining how IP is carried over those technologies, leaving the other layers of the IPS and applications that use those protocol unchanged.2.1.3.2. Lower-Layer Networks
The network layer can be recursively subdivided as needed. This may be accomplished by tunneling, in which an IP datagram is encapsulated in another IP header for delivery to a decapsulator. IP is frequently carried in Virtual Private Networks (VPNs) across the public Internet using tunneling technologies such as the Tunnel mode of IPsec, IP-in-IP, and Generic Route Encapsulation (GRE) [RFC2784]. In addition, IP is also frequently carried in circuit networks such as MPLS [RFC4364], GMPLS, and ATM. Finally, IP is also carried over wireless networks (IEEE 802.11, 802.15.4, or 802.16) and switched Ethernet (IEEE 802.3) networks.2.1.4. Media Layers: Physical and Link
At the lowest layer of the IP architecture, data is encoded in messages and transmitted over the physical media. While the IETF specifies algorithms for carrying IPv4 and IPv6 various media types, it rarely actually defines the media -- it happily uses specifications from IEEE, ITU, and other sources.2.2. Security Issues
While complaining about the security of the Internet is popular, it is important to distinguish between attacks on protocols and attacks on users (e.g., phishing). Attacks on users are largely independent of protocol details, reflecting interface design issues or user education problems, and are out of scope for this document. Security problems with Internet protocols are in scope, of course, and can
often be mitigated using existing security features already specified for the protocol, or by leveraging the security services offered by other IETF protocols. See the Security Assessment of the Transmission Control Protocol (TCP) [TCP-SEC] and the Security Assessment of the Internet Protocol version 4 [IP-SEC] for more information on TCP and IPv4 issues, respectively. These solutions do, however, need to get deployed as well. The road to widespread deployment can sometimes be painful since often multiple stakeholders need to take actions. Experience has shown that this takes some time, and very often only happens when the incentives are high enough in relation to the costs. Furthermore, it is important to stress that available standards are important, but the range of security problems is larger than a missing standard; many security problems are the result of implementation bugs and the result of certain deployment choices. While these are outside the realm of standards development, they play an important role in the security of the overall system. Security has to be integrated into the entire process. The IETF takes security seriously in the design of their protocols and architectures; every IETF specification has to have a Security Considerations section to document the offered security threats and countermeasures. RFC 3552 [RFC3552] provides recommendations on writing such a Security Considerations section. It also describes the classical Internet security threat model and lists common security goals. In a nutshell, security has to be integrated into every protocol, protocol extension, and consequently, every layer of the protocol stack to be useful. We illustrate this also throughout this document with references to further security discussions. Our experience has shown that dealing with security as an afterthought does not lead to the desired outcome. The discussion of security threats and available security mechanisms aims to illustrate some of the design aspects that commonly appear.2.2.1. Physical and Data Link Layer Security
At the physical and data link layers, threats generally center on physical attacks on the network -- the effects of backhoes, deterioration of physical media, and various kinds of environmental noise. Radio-based networks are subject to signal fade due to distance, interference, and environmental factors; it is widely noted that IEEE 802.15.4 networks frequently place a metal ground plate between the meter and the device that manages it. Fiber was at one
time deployed because it was believed to be untappable; we have since learned to tap it by bending the fiber and collecting incidental light, and we have learned about backhoes. As a result, some installations encase fiber optic cable in a pressurized sheath, both to quickly identify the location of a cut and to make it more difficult to tap. While there are protocol behaviors that can detect certain classes of physical faults, such as keep-alive exchanges, physical security is generally not considered to be a protocol problem. For wireless transmission technologies, eavesdropping on the transmitted frames is also typically a concern. Additionally, those operating networks may want to ensure that access to their infrastructure is restricted to those who are authenticated and authorized (typically called 'network access authentication'). This procedure is often offered by security primitives at the data link layer.2.2.2. Network, Transport, and Application Layer Security
At the network, transport, and application layers, it is common to demand a few basic security requirements, commonly referred to as CIA (Confidentiality, Integrity, and Availability): 1. Confidentiality: Protect the transmitted data from unauthorized disclosure (i.e., keep eavesdroppers from learning what was transmitted). For example, for trust in e-commerce applications, credit card transactions are exchanged encrypted between the Web browser and a Web server. 2. Integrity: Protect against unauthorized changes to exchanges, including both intentional change or destruction and accidental change or loss, by ensuring that changes to exchanges are detectable. It has two parts: one for the data and one for the peers. * Peers need to verify that information that appears to be from a trusted peer is really from that peer. This is typically called 'data origin authentication'. * Peers need to validate that the content of the data exchanged is unmodified. The term typically used for this property is 'data integrity'. 3. Availability: Ensure that the resource is accessible by mitigating of denial-of-service attacks.
To this we add authenticity, which requires that the communicating peers prove that they are in fact who they say they are to each other (i.e., mutual authentication). This generally means knowing "who" the peer is, and that they demonstrate the possession of a "secret" as part of the security protocol interaction. The following three examples aim to illustrate these security requirements. One common attack against a TCP session is to bombard the session with reset messages. Other attacks against TCP include the "SYN flooding" attack, in which an attacker attempts to exhaust the memory of the target by creating TCP state. In particular, the attacker attempts to exhaust the target's memory by opening a large number of unique TCP connections, each of which is represented by a Transmission Control Block (TCB). The attack is successful if the attacker can cause the target to fill its memory with TCBs. A number of mechanisms have been developed to deal with these types of denial-of-service attacks. One, "SYN Cookies", delays state establishment on the server side to a later phase in the protocol exchange. Another mechanism, specifically targeting the reset attack cited above, provides authentication services in TCP itself to ensure that fake resets are rejected. Another approach would be to offer security protection already at a lower layer, such as IPsec (see Section 3.1.2) or TLS (see Section 3.1.3), so that a host can identify legitimate messages and discard the others, thus mitigating any damage that may have been caused by the attack. Another common attack involves unauthorized access to resources. For example, an unauthorized party might try to attach to a network. To protect against such an attack, an Internet Service Provider (ISP) typically requires network access authentication of new hosts demanding access to the network and to the Internet prior to offering access. This exchange typically requires authentication of that entity and a check in the ISPs back-end database to determine whether corresponding subscriber records exist and are still valid (e.g., active subscription and sufficient credits). From the discussion above, establishing a secure communication channel is clearly an important concept frequently used to mitigate a range of attacks. Unfortunately, focusing only on channel security may not be enough for a given task. Threat models have evolved and even some of the communication endpoints cannot be considered fully trustworthy, i.e., even trusted peers may act maliciously.
Furthermore, many protocols are more sophisticated in their protocol interaction and involve more than two parties in the protocol exchange. Many of the application layer protocols, such as email, instant messaging, voice over IP, and presence-based applications, fall into this category. With this class of protocols, secure data, such as DNS records, and secure communications with middleware, intermediate servers, and supporting applications need to be considered as well as the security of the direct communication. A detailed treatment of the security threats and requirements of these multi-party protocols is beyond this specification but the interested reader is referred to the above-mentioned examples for an illustration of what technical mechanisms have been investigated and proposed in the past.2.3. Network Infrastructure
While the following protocols are not critical to the design of a specific system, they are important to running a network, and as such are surveyed here.2.3.1. Domain Name System (DNS)
The DNS' main function is translating names to numeric IP addresses. While this is not critical to running a network, certain functions are made a lot easier if numeric addresses can be replaced with mnemonic names. This facilitates renumbering of networks and generally improves the manageability and serviceability of the network. DNS has a set of security extensions called DNSSEC, which can be used to provide strong cryptographic authentication to the DNS. DNS and DNSSEC are discussed further in Section 3.4.1.2.3.2. Network Management
Network management has proven to be a difficult problem. As such, various solutions have been proposed, implemented, and deployed. Each solution has its proponents, all of whom have solid arguments for their viewpoints. The IETF has two major network management solutions for device operation: SNMP, which is ASN.1-encoded and is primarily used for monitoring of system variables, and NETCONF [RFC4741], which is XML-encoded and primarily used for device configuration. Another aspect of network management is the initial provisioning and configuration of hosts, which is discussed in Section 3.4.2. Note that Smart Grid deployments may require identity authentication and authorization (as well as other provisioning and configuration) that may not be within the scope of either DHCP or Neighbor Discovery. While the IP Protocol Suite has limited support for secure
provisioning and configuration, these problems have been solved using IP protocols in specifications such as DOCSIS 3.0 [SP-MULPIv3.0].
(page 14 continued on part 2)