diff options
Diffstat (limited to 'doc/rfc/rfc6272.txt')
| -rw-r--r-- | doc/rfc/rfc6272.txt | 3699 |
1 files changed, 3699 insertions, 0 deletions
diff --git a/doc/rfc/rfc6272.txt b/doc/rfc/rfc6272.txt new file mode 100644 index 0000000..c04aa8e --- /dev/null +++ b/doc/rfc/rfc6272.txt @@ -0,0 +1,3699 @@ + + + + + + +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 Grid + +Abstract + + 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. + + + + +Baker & Meyer Informational [Page 1] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +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 + + + + +Baker & Meyer Informational [Page 2] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + 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 + + + + + + + + + + + + + + + +Baker & Meyer Informational [Page 3] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +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. + + + + +Baker & Meyer Informational [Page 4] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + 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. + + + +Baker & Meyer Informational [Page 5] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +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. + + + + + + + + + + + + + + + +Baker & Meyer Informational [Page 6] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + +---------------------------------+ + |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 Model + +2.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. + + + + + + +Baker & Meyer Informational [Page 7] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +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. + + + +Baker & Meyer Informational [Page 8] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +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 + + + +Baker & Meyer Informational [Page 9] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + 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 + + + +Baker & Meyer Informational [Page 10] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + 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. + + + + +Baker & Meyer Informational [Page 11] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + 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. + + + + +Baker & Meyer Informational [Page 12] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + 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 + + + +Baker & Meyer Informational [Page 13] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + provisioning and configuration, these problems have been solved using + IP protocols in specifications such as DOCSIS 3.0 [SP-MULPIv3.0]. + +3. Specific Protocols + + In this section, having briefly laid out the IP architecture and some + of the problems that the architecture tries to address, we introduce + specific protocols that might be appropriate to various Smart Grid + use cases. Use cases should be analyzed along with privacy, + Authentication, Authorization, and Accounting (AAA), transport, and + network solution dimensions. The following sections provide guidance + for such analysis. + +3.1. Security Toolbox + + As noted, a key consideration in security solutions is a good threat + analysis coupled with appropriate mitigation strategies at each + layer. The IETF has over time developed a number of building blocks + for security based on the observation that protocols often demand + similar security services. The following sub-sections outline a few + of those commonly used security building blocks. Reusing them offers + several advantages, such as availability of open source code, + experience with existing systems, a number of extensions that have + been developed, and the confidence that the listed technologies have + been reviewed and analyzed by a number of security experts. + + It is important to highlight that in addition to the mentioned + security tools, every protocol often comes with additional, often + unique security considerations that are specific to the domain in + which the protocol operates. Many protocols include features + specifically designed to mitigate these protocol-specific risks. In + other cases, the security considerations will identify security- + relevant services that are required from other network layers to + achieve appropriate levels of security. + +3.1.1. Authentication, Authorization, and Accounting (AAA) + + While the term AAA sounds generic and applicable to all sorts of + security protocols, it has been, in the IETF, used in relation to + network access authentication and is associated with the RADIUS + ([RFC2865]) and the Diameter protocol ([RFC3588], [DIME-BASE]) in + particular. + + The authentication procedure for network access aims to deal with the + task of verifying that a peer is authenticated and authorized prior + to accessing a particular resource (often connectivity to the + Internet). Typically, the authentication architecture for network + access consists of the following building blocks: the Extensible + + + +Baker & Meyer Informational [Page 14] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + Authentication Protocol (EAP [RFC4017]) as a container to encapsulate + EAP methods, an EAP Method (as a specific way to perform + cryptographic authentication and key exchange, such as described in + RFC 5216 [RFC5216] and RFC 5433 [RFC5433]), a protocol that carries + EAP payloads between the end host and a server-side entity (such as a + network access server), and a way to carry EAP payloads to back-end + server infrastructure (potentially in a cross-domain scenario) to + provide authorization and accounting functionality. The latter part + is provided by RADIUS and Diameter. To carry EAP payloads between + the end host and a network access server, different mechanisms have + been standardized, such as the Protocol for Carrying Authentication + for Network Access (PANA) [RFC5191] and IEEE 802.1X [IEEE802.1X]. + For access to remote networks, such as enterprise networks, the + ability to utilize EAP within IKEv2 [RFC5996] has also been + developed. + + More recently, the same architecture with EAP and RADIUS/Diameter is + being reused for application layer protocols. More details about + this architectural variant can be found in [ABFAB-ARCH]. + +3.1.2. Network Layer Security + + IP security, as described in [RFC4301], addresses security at the IP + layer, provided through the use of a combination of cryptographic and + protocol security mechanisms. It offers a set of security services + for traffic at the IP layer, in both the IPv4 and IPv6 environment. + The set of security services offered includes access control, + connectionless integrity, data origin authentication, detection and + rejection of replays (a form of partial sequence integrity), + confidentiality (via encryption), and limited traffic-flow + confidentiality. These services are provided at the IP layer, + offering protection in a standard fashion for all protocols that may + be carried over IP (including IP itself). + + The architecture foresees a split between the rather time-consuming + (a) authentication and key exchange protocol step that also + establishes a security association (a data structure with keying + material and security parameters) and (b) the actual data traffic + protection. + + For the former step, the Internet Key Exchange protocol version 2 + (IKEv2 [RFC5996]) is the most recent edition of the standardized + protocol. IKE negotiates each of the cryptographic algorithms that + will be used to protect the data independently, somewhat like + selecting items a la carte. + + For the actual data protection, two types of protocols have + historically been used, namely the IP Authentication Header (AH) + + + +Baker & Meyer Informational [Page 15] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC4302] and the Encapsulating Security Payload (ESP) [RFC4303]. + The two differ in the security services they offer; the most + important distinction is that ESP offers confidentiality protection + while AH does not. Since ESP can also provide authentication + services, most recent protocol developments making use of IPsec only + specify use of ESP and do not use AH. + + In addition to these base line protocol mechanisms a number of + extensions have been developed for IKEv2 (e.g., an extension to + perform EAP-only authentication [RFC5998]) and since the architecture + supports flexible treatment of cryptographic algorithms a number of + them have been specified (e.g., [RFC4307] for IKEv2, and [RFC4835] + for AH and ESP). + +3.1.3. Transport Layer Security + + Transport Layer Security v1.2 [RFC5246] are security services that + protect data above the transport layer. The protocol allows client/ + server applications to communicate in a way that is designed to + prevent eavesdropping, tampering, or message forgery. TLS is + application protocol independent. + + TLS is composed of two layers: the TLS Record protocol and the TLS + Handshake protocol. The TLS Record protocol provides connection + security that has two basic properties: (a) confidentiality + protection and (b) integrity protection. + + The TLS Handshake protocol allows the server and client to + authenticate each other and to negotiate an encryption algorithm and + cryptographic keys before the application protocol transmits or + receives its first byte of data. The negotiated parameters and the + derived keying material is then used by the TLS Record protocol to + perform its job. + + Unlike IKEv2/IPsec, TLS negotiates these cryptographic parameters in + suites, so-called 'cipher suites'. Examples of cipher suites that + can be negotiated with TLS include Elliptic Curve Cryptography (ECC) + [RFC4492] [RFC5289] [AES-CCM-ECC], Camellia [RFC5932], and the Suite + B Profile [RFC5430]. [IEC62351-3] outlines the use of different TLS + cipher suites for use in the Smart Grid. The basic cryptographic + mechanisms for ECC have been documented in [RFC6090]. + + TLS must run over a reliable transport channel -- typically TCP. In + order to offer the same security services for unreliable datagram + traffic, such as UDP, the Datagram Transport Layer Security (DTLS + [RFC4347] [DTLS]) was developed. + + + + + +Baker & Meyer Informational [Page 16] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +3.1.4. Application Layer Security + + In certain cases, the application layer independent security + mechanisms described in the previous sub-sections are not sufficient + to deal with all the identified threats. For this purpose, a number + of security primitives are additionally available at the application + layer where the semantic of the application can be considered. + + We will focus our description on a few mechanisms that are commonly + used throughout the Internet. + + Cryptographic Message Syntax (CMS [RFC5652]) is an encapsulation + syntax to sign, digest, authenticate, or encrypt arbitrary message + content. It also allows arbitrary attributes, such as signing time, + to be signed along with the message content, and it provides for + other attributes such as countersignatures to be associated with a + signature. The CMS can support a variety of architectures for + certificate-based key management, such as the one defined by the PKIX + (Public Key Infrastructure using X.509) working group [RFC5280]. The + CMS has been leveraged to supply security services in a variety of + protocols, including secure email [RFC5751], key management [RFC5958] + [RFC6031], and firmware updates [RFC4108]. + + Related work includes the use of digital signatures on XML-encoded + documents, which has been jointly standardized by W3C and the IETF + [RFC3275]. Digitally signed XML is a good choice where applications + natively support XML-encoded data, such as the Extensible Messaging + and Presence Protocol (XMPP). + + More recently, the work on delegated authentication and authorization + often demanded by Web applications have been developed with the Open + Web Authentication (OAuth) protocol [RFC5849] [OAUTHv2]. OAuth is + used by third-party applications to gain access to protected + resources (such as energy consumption information about a specific + household) without having the resource owner share its long-term + credentials with that third-party. In OAuth, the third-party + application requests access to resources controlled by the resource + owner and hosted by the resource server, and is issued a different + set of credentials than those of the resource owner. More + specifically, the third-party applications obtain an access token + during the OAuth protocol exchange. This token denotes a specific + scope, duration, and other access attributes. As a result, it + securely gains access to the protected resource with the consent of + the resource owner. + + + + + + + +Baker & Meyer Informational [Page 17] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +3.1.5. Secure Shell + + The Secure Shell (SSH) protocol [RFC4253] has been widely used by + administrators and others for secure remote login, but is also usable + for secure tunneling. More recently, protocols have chosen to layer + on top of SSH for transport security services; for example, the + NETCONF network management protocol (see Section 3.5.2) uses SSH as + its main communications security protocol. + +3.1.6. Key Management Infrastructures + + All of the security protocols discussed above depend on cryptography + for security, and hence require some form of key management. Most + IETF protocols at least nominally require some scalable form of key + management to be defined as mandatory to implement; indeed the lack + of such key management features has in the past been a reason to + delay approval of protocols. There are two generic key management + schemes that are widely used by other Internet protocols, PKIX and + Kerberos, each of which is briefly described below. + +3.1.6.1. PKIX + + Public Key Infrastructure (PKI) refers to the kind of key management + that is based on certification authorities (CAs) issuing public key + certificates for other key holders. By chaining from a trust anchor + (a locally trusted copy of a CA public key) down to the public key of + some protocol peer, PKI allows for secure binding between keys and + protocol-specific names, such as email addresses, and hence enables + security services such as data and peer authentication, data + integrity, and confidentiality (encryption). + + The main Internet standard for PKI is [RFC5280], which is a profile + of the X.509 public key certificate format. There are a range of + private and commercial CAs operating today providing the ability to + manage and securely distribute keys for all protocols that use public + key certificates, e.g., TLS and S/MIME. In addition to the profile + standard, the PKIX working group has defined a number of management + protocols (e.g., [RFC5272] and [RFC4210]) as well as protocols for + handling revocation of public key certificates such as the Online + Certificate Status Protocol (OCSP) [RFC2560]. + + PKI is generally perceived to better handle use-cases spanning + multiple independent domains when compared to Kerberos. + + + + + + + + +Baker & Meyer Informational [Page 18] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +3.1.6.2. Kerberos + + The Kerberos Network Authentication System [RFC4120] is commonly used + within organizations to centralize authentication, authorization, and + policy in one place. Kerberos natively supports usernames and + passwords as the basis of authentication. With Public Key + Cryptography for Initial Authentication in Kerberos (PKINIT) + [RFC4556], Kerberos supports certificate or public-key-based + authentication. This may provide an advantage by concentrating + policy about certificate validation and mapping of certificates to + user accounts in one place. Through the GSS-API [RFC1964] [RFC2743] + [RFC4121], Kerberos can be used to manage authentication for most + applications. While Kerberos works best within organizations and + enterprises, it does have facilities that permit authentication to be + shared between administrative domains. + +3.2. Network Layer + + The IPS specifies two network layer protocols: IPv4 and IPv6. The + following sections describe the IETF's coexistence and transition + mechanisms for IPv4 and IPv6. + + Note that on 3 February 2011, the IANA's IPv4 free pool (the pool of + available, unallocated IPv4 addresses) was exhausted, and the + Regional Internet Registrars' (RIRs') free pools are expected to be + exhausted during the coming year, if not sooner. The IETF, the IANA, + and the RIRs recommend that new deployments use IPv6, and that IPv4 + infrastructures be supported via the mechanisms described in + Section 3.2.1. + +3.2.1. IPv4/IPv6 Coexistence Advice + + The IETF has specified a variety of mechanisms designed to facilitate + IPv4/IPv6 coexistence. The IETF actually recommends relatively few + of them: the current advice to network operators is found in + Guidelines for Using IPv6 Transition Mechanisms [RFC6180]. The + thoughts in that document are replicated here. + +3.2.1.1. Dual Stack Coexistence + + The simplest coexistence approach is to + + o provide a network that routes both IPv4 and IPv6, + + o ensure that servers and their applications similarly support both + protocols, and + + + + + +Baker & Meyer Informational [Page 19] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + o require that all new systems and applications purchased or + upgraded support both protocols. + + The net result is that over time all systems become protocol + agnostic, and that eventually maintenance of IPv4 support becomes a + business decision. This approach is described in the Basic + Transition Mechanisms for IPv6 Hosts and Routers [RFC4213]. + +3.2.1.2. Tunneling Mechanism + + In those places in the network that support only IPv4, the simplest + and most reliable approach to coexistence is to provide virtual + connectivity using tunnels or encapsulations. Early in IPv6 + deployment, this was often done using static tunnels. A more dynamic + approach is documented in IPv6 Rapid Deployment on IPv4 + Infrastructures (6rd) [RFC5569]. + +3.2.1.3. Translation between IPv4 and IPv6 Networks + + In those cases where an IPv4-only host would like to communicate with + an IPv6-only host (or vice versa), a need for protocol translation + may be indicated. At first blush, protocol translation may appear + trivial; on deeper inspection, it turns out that protocol translation + can be complicated. + + The most reliable approach to protocol translation is to provide + application layer proxies or gateways, which natively enable + application-to-application connections using both protocols and can + use whichever is appropriate. For example, a web proxy might use + both protocols and as a result enable an IPv4-only system to run HTTP + across an IPv6-only network or to a web server that implements only + IPv6. Since this approach is a service of a protocol-agnostic + server, it is not the subject of standardization by the IETF. + + For those applications in which network layer translation is + indicated, the IETF has designed a translation mechanism, which is + described in the following documents: + + o Framework for IPv4/IPv6 Translation [RFC6144] + + o IPv6 Addressing of IPv4/IPv6 Translators [RFC6052] + + o DNS extensions [RFC6147] + + o IP/ICMP Translation Algorithm [RFC6145] + + o Translation from IPv6 Clients to IPv4 Servers [RFC6146] + + + + +Baker & Meyer Informational [Page 20] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + As with IPv4/IPv4 Network Address Translation, translation between + IPv4 and IPv6 has limited real world applicability for an application + protocol that carries IP addresses in its payload and expects those + addresses to be meaningful to both client and server. However, for + those protocols that do not, protocol translation can provide a + useful network extension. + + Network-based translation provides for two types of services: + stateless (and therefore scalable and load-sharable) translation + between IPv4 and IPv6 addresses that embed an IPv4 address in them, + and stateful translation similar to IPv4/IPv4 translation between + IPv4 addresses. The stateless mode is straightforward to implement, + but due to the embedding, requires IPv4 addresses to be allocated to + an otherwise IPv6-only network, and is primarily useful for IPv4- + accessible servers implemented in the IPv6 network. The stateful + mode allows clients in the IPv6 network to access servers in the IPv4 + network, but does not provide such service for IPv4 clients accessing + IPv6 peers or servers with general addresses; it has the advantage + that it does not require that a unique IPv4 address be embedded in + the IPv6 address of hosts using this mechanism. + + Finally, note that some site networks are IPv6 only while some + transit networks are IPv4 only. In these cases, it may be necessary + to tunnel IPv6 over IPv4 or translate between IPv6 and IPv4. + +3.2.2. Internet Protocol Version 4 + + IPv4 [RFC0791] and the Internet Control Message Protocol (ICMP) + [RFC0792] comprise the IPv4 network layer. IPv4 provides unreliable + delivery of datagrams. + + IPv4 also provides for fragmentation and reassembly of long datagrams + for transmission through networks with small Maximum Transmission + Units (MTU). The MTU is the largest packet size that can be + delivered across the network. In addition, the IPS provides ICMP + [RFC0792], which is a separate protocol that enables the network to + report errors and other issues to hosts that originate problematic + datagrams. + + IPv4 originally supported an experimental type of service field that + identified eight levels of operational precedence styled after the + requirements of military telephony, plus three and later four bit + flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2 + [RFC2328] interpreted as control traffic; this control traffic is + assured of not being dropped when queued or upon receipt, even if + other traffic is being dropped. These control bits turned out to be + less useful than the designers had hoped. They were replaced by the + Differentiated Services Architecture [RFC2474] [RFC2475], which + + + +Baker & Meyer Informational [Page 21] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + contains a six-bit code point used to select an algorithm (a "per-hop + behavior") to be applied to the datagram. The IETF has also produced + a set of Configuration Guidelines for DiffServ Service Classes + [RFC4594], which describes a set of service classes that may be + useful to a network operator. + +3.2.2.1. IPv4 Address Allocation and Assignment + + IPv4 addresses are administratively assigned, usually using automated + methods, using the Dynamic Host Configuration Protocol (DHCP) + [RFC2131]. On most interface types, neighboring systems identify + each others' addresses using the Address Resolution Protocol (ARP) + [RFC0826]. + +3.2.2.2. IPv4 Unicast Routing + + Routing for the IPv4 Internet is accomplished by routing applications + that exchange connectivity information and build semi-static + destination routing databases. If a datagram is directed to a given + destination address, the address is looked up in the routing + database, and the most specific ("longest") prefix found that + contains it is used to identify the next-hop router or the end system + to which it will be delivered. This is not generally implemented on + hosts, although it can be; a host normally sends datagrams to a + router on its local network, and the router carries out the intent. + + IETF specified routing protocols include RIP Version 2 [RFC2453], OSI + IS-IS for IPv4 [RFC1195], OSPF Version 2 [RFC2328], and BGP-4 + [RFC4271]. Active research exists in mobile ad hoc routing and other + routing paradigms; these result in new protocols and modified + forwarding paradigms. + +3.2.2.3. IPv4 Multicast Forwarding and Routing + + IPv4 was originally specified as a unicast (point to point) protocol, + and was extended to support multicast in [RFC1112]. This uses the + Internet Group Management Protocol [RFC3376] [RFC4604] to enable + applications to join multicast groups, and for most applications uses + Source-Specific Multicast [RFC4607] for routing and delivery of + multicast messages. + + An experiment carried out in IPv4 that is not part of the core + Internet architecture but may be of interest in the Smart Grid is the + development of so-called "Reliable Multicast". This is "so-called" + because it is not "reliable" in the strict sense of the word -- it is + perhaps better described as "enhanced reliability". A best effort + network by definition can lose traffic, duplicate it, or reorder it, + something as true for multicast as for unicast. Research in + + + +Baker & Meyer Informational [Page 22] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + "Reliable Multicast" technology intends to improve the probability of + delivery of multicast traffic. + + In that research, the IETF imposed guidelines [RFC2357] on the + research community regarding what was desirable. Important results + from that research include a number of papers and several proprietary + protocols including some that have been used in support of business + operations. RFCs in the area include The Use of Forward Error + Correction (FEC) in Reliable Multicast [RFC3453], the Negative- + acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol + [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP) + [RFC4410]. + +3.2.3. Internet Protocol Version 6 + + IPv6 [RFC2460], with the Internet Control Message Protocol "v6" + [RFC4443], constitutes the next generation protocol for the Internet. + IPv6 provides for transmission of datagrams from source to + destination hosts, which are identified by fixed-length addresses. + + IPv6 also provides for fragmentation and reassembly of long datagrams + by the originating host, if necessary, for transmission through + "small packet" networks. ICMPv6, which is a separate protocol + implemented along with IPv6, enables the network to report errors and + other issues to hosts that originate problematic datagrams. + + IPv6 adopted the Differentiated Services Architecture [RFC2474] + [RFC2475], which contains a six-bit code point used to select an + algorithm (a "per-hop behavior") to be applied to the datagram. + + The IPv6 over Low-Power Wireless Personal Area Networks RFC [RFC4919] + and the Compression Format for IPv6 Datagrams in 6LoWPAN Networks + document [6LOWPAN-HC] addresses IPv6 header compression and subnet + architecture in at least some sensor networks, and may be appropriate + to the Smart Grid Advanced Metering Infrastructure or other sensor + domains. + +3.2.3.1. IPv6 Address Allocation and Assignment + + An IPv6 Address [RFC4291] may be administratively assigned using + DHCPv6 [RFC3315] in a manner similar to the way IPv4 addresses are. + In addition, IPv6 addresses may also be autoconfigured. + Autoconfiguration enables various models of network management that + may be advantageous in different use cases. Autoconfiguration + procedures are defined in [RFC4862] and [RFC4941]. IPv6 neighbors + identify each others' addresses using Neighbor Discovery (ND) + [RFC4861]. SEcure Neighbor Discovery (SEND) [RFC3971] may be used to + secure these operations. + + + +Baker & Meyer Informational [Page 23] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +3.2.3.2. IPv6 Routing + + Routing for the IPv6 Internet is accomplished by routing applications + that exchange connectivity information and build semi-static + destination routing databases. If a datagram is directed to a given + destination address, the address is looked up in the routing + database, and the most specific ("longest") prefix found that + contains it is used to identify the next-hop router or the end system + to which it will be delivered. Routing is not generally implemented + on hosts (although it can be); generally, a host sends datagrams to a + router on its local network, and the router carries out the intent. + + IETF-specified routing protocols include RIP for IPv6 [RFC2080], + IS-IS for IPv6 [RFC5308], OSPF for IPv6 [RFC5340], and BGP-4 for IPv6 + [RFC2545]. Active research exists in mobile ad hoc routing, routing + in low-power networks (sensors and Smart Grids), and other routing + paradigms; these result in new protocols and modified forwarding + paradigms. + +3.2.4. Routing for IPv4 and IPv6 + +3.2.4.1. Routing Information Protocol + + The prototypical routing protocol used in the Internet has probably + been the Routing Information Protocol [RFC1058]. People that use it + today tend to deploy RIPng for IPv6 [RFC2080] and RIP Version 2 + [RFC2453]. Briefly, RIP is a distance vector routing protocol that + is based on a distributed variant of the widely known Bellman-Ford + algorithm. In distance vector routing protocols, each router + announces the contents of its route table to neighboring routers, + which integrate the results with their route tables and re-announce + them to others. It has been characterized as "routing by rumor", and + suffers many of the ills we find in human gossip -- propagating stale + or incorrect information in certain failure scenarios, and being in + cases unresponsive to changes in topology. [RFC1058] provides + guidance to algorithm designers to mitigate these issues. + +3.2.4.2. Open Shortest Path First + + The Open Shortest Path First (OSPF) routing protocol is one of the + more widely used protocols in the Internet. OSPF is based on + Dijkstra's well known Shortest Path First (SPF) algorithm. It is + implemented as OSPF Version 2 [RFC2328] for IPv4, OSPF for IPv6 + [RFC5340] for IPv6, and the Support of Address Families in OSPFv3 + [RFC5838] to enable [RFC5340] routing both IPv4 and IPv6. + + The advantage of any SPF-based protocol (i.e., OSPF and IS-IS) is + primarily that every router in the network constructs its view of the + + + +Baker & Meyer Informational [Page 24] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + network from first-hand knowledge rather than the "gossip" that + distance vector protocols propagate. As such, the topology is + quickly and easily changed by simply announcing the change. The + disadvantage of SPF-based protocols is that each router must store a + first-person statement of the connectivity of each router in the + domain. + +3.2.4.3. ISO Intermediate System to Intermediate System + + The Intermediate System to Intermediate System (IS-IS) routing + protocol is one of the more widely used protocols in the Internet. + IS-IS is also based on Dijkstra's SPF algorithm. It was originally + specified as ISO DP 10589 for the routing of Connectionless Network + Service (CLNS), and extended for routing in TCP/IP and dual + environments [RFC1195], and more recently for routing of IPv6 + [RFC5308]. + + As with OSPF, the positives of any SPF-based protocol and + specifically IS-IS are primarily that the network is described as a + lattice of routers with connectivity to subnets and isolated hosts. + It's topology is quickly and easily changed by simply announcing the + change, without the issues of "routing by rumor", since every host + within the routing domain has a first-person statement of the + connectivity of each router in the domain. The negatives are a + corollary: each router must store a first-person statement of the + connectivity of each router in the domain. + +3.2.4.4. Border Gateway Protocol + + The Border Gateway Protocol (BGP) [RFC4271] is widely used in the + IPv4 Internet to exchange routes between administrative entities -- + service providers, their peers, their upstream networks, and their + customers -- while applying specific policy. Multiprotocol + Extensions [RFC4760] to BGP allow BGP to carry IPv6 Inter-Domain + Routing [RFC2545], multicast reachability information, and VPN + information, among others. + + Considerations that apply with BGP deal with the flexibility and + complexity of the policies that must be defined. Flexibility is a + good thing; in a network that is not run by professionals, the + complexity is burdensome. + +3.2.4.5. Dynamic MANET On-Demand (DYMO) Routing + + The Mobile Ad Hoc working group of the IETF developed, among other + protocols, Ad hoc On-Demand Distance Vector (AODV) Routing [RFC3561]. + This protocol captured the minds of some in the embedded devices + industry, but experienced issues in wireless networks such as + + + +Baker & Meyer Informational [Page 25] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + 802.15.4 and 802.11's Ad Hoc mode. As a result, it is in the process + of being updated in the Dynamic MANET On-demand (DYMO) Routing + protocol [DYMO]. + + AODV and DYMO are essentially reactive routing protocols designed for + mobile ad hoc networks, and usable in other forms of ad hoc networks. + They provide connectivity between a device within a distributed + subnet and a few devices (including perhaps a gateway or router to + another subnet) without tracking connectivity to other devices. In + essence, routing is calculated and discovered upon need, and a host + or router need only maintain the routes that currently work and are + needed. + +3.2.4.6. Optimized Link State Routing Protocol + + The Optimized Link State Routing Protocol (OLSR) [RFC3626] is a + proactive routing protocol designed for mobile ad hoc networks, and + can be used in other forms of ad hoc networks. It provides arbitrary + connectivity between systems within a distributed subnet. As with + protocols designed for wired networks, routing is calculated whenever + changes are detected, and maintained in each router's tables. The + set of nodes that operate as routers within the subnet, however, are + fairly fluid, and dependent on this instantaneous topology of the + subnet. + +3.2.4.7. Routing for Low-Power and Lossy Networks + + The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) + [RPL] is a reactive routing protocol designed for use in resource + constrained networks. Requirements for resource constrained networks + are defined in [RFC5548], [RFC5673], [RFC5826], and [RFC5867]. + + Briefly, a constrained network is comprised of nodes that: + + o Are built with limited processing power and memory, and sometimes + energy when operating on batteries. + + o Are interconnected through a low-data-rate network interface and + are potentially vulnerable to communication instability and low + packet delivery rates. + + o Potentially have a mix of roles such as being able to act as a + host (i.e., generating traffic) and/or a router (i.e., both + forwarding and generating RPL traffic). + + + + + + + +Baker & Meyer Informational [Page 26] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +3.2.5. IPv6 Multicast Forwarding and Routing + + IPv6 specifies both unicast and multicast datagram exchange. This + uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710] + [RFC3590] [RFC3810] [RFC4604] to enable applications to join + multicast groups, and for most applications uses Source-Specific + Multicast [RFC4607] for routing and delivery of multicast messages. + + The mechanisms experimentally developed for reliable multicast in + IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well. + +3.2.5.1. Protocol-Independent Multicast Routing + + A multicast routing protocol has two basic functions: building the + multicast distribution tree and forwarding multicast traffic. + Multicast routing protocols generally contain a control plane for + building distribution trees, and a forwarding plane that uses the + distribution tree when forwarding multicast traffic. + + The multicast model works as follows: hosts express their interest in + receiving multicast traffic from a source by sending a Join message + to their first-hop router. That router in turn sends a Join message + upstream towards the root of the tree, grafting the router (leaf + node) onto the distribution tree for the group. Data is delivered + down the tree toward the leaf nodes, which forward it onto the local + network for delivery. + + The initial multicast model deployed in the Internet was known as + Any-Source Multicast (ASM). In the ASM model, any host could send to + the group and inter-domain multicast was difficult. Protocols such + as Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol + Specification (Revised) [RFC3973] and Protocol Independent Multicast + - Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601] + were designed for the ASM model. + + Many modern multicast deployments use Source-Specific Multicast (PIM- + SSM) [RFC3569][RFC4608]. In the SSM model, a host expresses interest + in a "channel", which is comprised of a source (S) and a group (G). + Distribution trees are rooted to the sending host (called an "(S,G) + tree"). Since only the source S can send on to the group, SSM has + inherent anti-jamming capability. In addition, inter-domain + multicast is simplified since finding the (S,G) channel they are + interested in receiving is the responsibility of the receivers + (rather than the networks). This implies that SSM requires some form + of directory service so that receivers can find the (S,G) channels. + + + + + + +Baker & Meyer Informational [Page 27] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +3.2.6. Adaptation to Lower-Layer Networks and Link Layer Protocols + + In general, the layered architecture of the Internet enables the IPS + to run over any appropriate layer two architecture. The ability to + change the link or physical layer without having to rethink the + network layer, transports, or applications has been a great benefit + in the Internet. + + Examples of link layer adaptation technology include: + + Ethernet/IEEE 802.3: IPv4 has run on each link layer environment + that uses the Ethernet header (which is to say 10 and 100 MBPS + wired Ethernet, 1 and 10 GBPS wired Ethernet, and the various + versions of IEEE 802.11) using [RFC0894]. IPv6 does the same + using [RFC2464]. + + PPP: The IETF has defined a serial line protocol, the Point-to-Point + Protocol (PPP) [RFC1661], that uses High-Level Data Link Control + (bit-synchronous or byte synchronous) framing. The IPv4 + adaptation specification is [RFC1332], and the IPv6 adaptation + specification is [RFC5072]. Current use of this protocol is in + traditional serial lines, authentication exchanges in DSL networks + using PPP Over Ethernet (PPPoE) [RFC2516], and the Digital + Signaling Hierarchy (generally referred to as Packet-on-SONET/SDH) + using PPP over SONET/SDH [RFC2615]. + + IEEE 802.15.4: The adaptation specification for IPv6 transmission + over IEEE 802.15.4 Networks is [RFC4944]. + + Numerous other adaptation specifications exist, including ATM, Frame + Relay, X.25, other standardized and proprietary LAN technologies, and + others. + +3.3. Transport Layer + + This section outlines the functionality of UDP, TCP, SCTP, and DCCP. + UDP and TCP are best known and most widely used in the Internet + today, while SCTP and DCCP are newer protocols that were built for + specific purposes. Other transport protocols can be built when + required. + +3.3.1. User Datagram Protocol (UDP) + + The User Datagram Protocol [RFC0768] and the Lightweight User + Datagram Protocol [RFC3828] are properly not "transport" protocols in + the sense of "a set of rules governing the exchange or transmission + of data electronically between devices". They are labels that + + + + +Baker & Meyer Informational [Page 28] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + provide for multiplexing of applications directly on the IP layer, + with transport functionality embedded in the application. + + Many exchange designs have been built using UDP, and many of them + have not worked out. As a result, the use of UDP really should be + treated as designing a new transport. Advice on the use of UDP in + new applications can be found in Unicast UDP Usage Guidelines for + Application Designers [RFC5405]. + + Datagram Transport Layer Security [RFC5238] can be used to prevent + eavesdropping, tampering, or message forgery for applications that + run over UDP. Alternatively, UDP can run over IPsec. + +3.3.2. Transmission Control Protocol (TCP) + + TCP [RFC0793] is the predominant transport protocol used in the + Internet. It is "reliable", as the term is used in protocol design: + it delivers data to its peer and provides acknowledgement to the + sender, or it dies trying. It has extensions for Congestion Control + [RFC5681] and Explicit Congestion Notification [RFC3168]. + + The user interface for TCP is a byte stream interface -- an + application using TCP might "write" to it several times only to have + the data compacted into a common segment and delivered as such to its + peer. For message-stream interfaces, ACSE/ROSE uses the ISO + Transport Service on TCP [RFC1006][RFC2126] in the application. + + Transport Layer Security [RFC5246] can be used to prevent + eavesdropping, tampering, or message forgery. Alternatively, TCP can + run over IPsec. Additionally, [RFC4987] discusses mechanisms similar + to SCTP's and DCCP's "cookie" approach that may be used to secure TCP + sessions against flooding attacks. + + Finally, note that TCP has been the subject of ongoing research and + development since it was written. The Roadmap for TCP Specification + Documents [RFC4614] captures this history, and is intended to be a + guide to current and future developers in the area. + +3.3.3. Stream Control Transmission Protocol (SCTP) + + SCTP [RFC4960] is a more recent reliable transport protocol that can + be imagined as a TCP-like context containing multiple separate and + independent message streams (unlike TCP's byte streams). The design + of SCTP includes appropriate congestion avoidance behavior and + resistance to flooding and masquerade attacks. As it uses a message + stream interface, it may also be more appropriate for the ISO + Transport Service than using RFC 1006/2126 to turn TCP's octet + streams into a message interface. + + + +Baker & Meyer Informational [Page 29] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + SCTP offers several delivery options. The basic service is + sequential non-duplicated delivery of messages within a stream, for + each stream in use. Since streams are independent, one stream may + pause due to head-of-line blocking while another stream in the same + session continues to deliver data. In addition, SCTP provides a + mechanism for bypassing the sequenced delivery service. User + messages sent using this mechanism are delivered to the SCTP user as + soon as they are received. + + SCTP implements a simple "cookie" mechanism intended to limit the + effectiveness of flooding attacks by mutual authentication. This + demonstrates that the application is connected to the same peer, but + does not identify the peer. Mechanisms also exist for Dynamic + Address Reconfiguration [RFC5061], enabling peers to change addresses + during the session and yet retain connectivity. Transport Layer + Security [RFC3436] can be used to prevent eavesdropping, tampering, + or message forgery. Alternatively, SCTP can run over IPsec. + +3.3.4. Datagram Congestion Control Protocol (DCCP) + + DCCP [RFC4340] is an "unreliable" transport protocol (e.g., one that + does not guarantee message delivery) that provides bidirectional + unicast connections of congestion-controlled unreliable datagrams. + DCCP is suitable for applications that transfer fairly large amounts + of data and that can benefit from control over the tradeoff between + timeliness and reliability. + + DCCP implements a simple "cookie" mechanism intended to limit the + effectiveness of flooding attacks by mutual authentication. This + demonstrates that the application is connected to the same peer, but + does not identify the peer. Datagram Transport Layer Security + [RFC5238] can be used to prevent eavesdropping, tampering, or message + forgery. Alternatively, DCCP can run over IPsec. + +3.4. Infrastructure + +3.4.1. Domain Name System + + In order to facilitate network management and operations, the + Internet community has defined the Domain Name System (DNS) [RFC1034] + [RFC1035]. Names are hierarchical: a name like example.com is found + registered with a .com registrar, and within the associated network + other names like baldur.cincinatti.example.com can be defined, with + obvious hierarchy. Security extensions, which allow a registry to + sign the records it contains and in so doing demonstrate their + authenticity, are defined by the DNS Security Extensions [RFC4033] + [RFC4034] [RFC4035]. + + + + +Baker & Meyer Informational [Page 30] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + Devices can also optionally update their own DNS record. For + example, a sensor that is using Stateless Address Autoconfiguration + [RFC4862] to create an address might want to associate it with a name + using DNS Dynamic Update [RFC2136] or DNS Secure Dynamic Update + [RFC3007]. + +3.4.2. Dynamic Host Configuration + + As discussed in Section 3.2.2, IPv4 address assignment is generally + performed using DHCP [RFC2131]. By contrast, Section 3.2.3 points + out that IPv6 address assignment can be accomplished using either + autoconfiguration [RFC4862] [RFC4941] or DHCPv6 [RFC3315]. The best + argument for the use of autoconfiguration is a large number of + systems that require little more than a random number as an address; + the argument for DHCP is administrative control. + + There are other parameters that may need to be allocated to hosts + requiring administrative configuration; examples include the + addresses of DNS servers, keys for Secure DNS, and Network Time + servers. + +3.4.3. Network Time + + The Network Time Protocol was originally designed by Dave Mills of + the University of Delaware and CSNET, implementing a temporal metric + in the Fuzzball Routing Protocol and generally coordinating time + experiments. The current versions of the time protocol are the + Network Time Protocol [RFC5905]. + +3.5. Network Management + + The IETF has developed two protocols for network management: SNMP and + NETCONF. SNMP is discussed in Section 3.5.1, and NETCONF is + discussed in Section 3.5.2. + +3.5.1. Simple Network Management Protocol (SNMP) + + The Simple Network Management Protocol, originally specified in the + late 1980's and having passed through several revisions, is specified + in several documents: + + o An Architecture for Describing Simple Network Management Protocol + (SNMP) Management Frameworks [RFC3411] + + o Message Processing and Dispatching [RFC3412] + + o SNMP Applications [RFC3413] + + + + +Baker & Meyer Informational [Page 31] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + o User-based Security Model (USM) for SNMP version 3 [RFC3414] + + o View-based Access Control Model (VACM) [RFC3415] + + o Version 2 of the SNMP Protocol Operations [RFC3416] + + o Transport Mappings [RFC3417] + + o Management Information Base (MIB) [RFC3418] + + It provides capabilities for polled and event-driven activities, and + for both monitoring and configuration of systems in the field. + Historically, it has been used primarily for monitoring nodes in a + network. Messages and their constituent data are encoded using a + profile of ASN.1. + +3.5.2. Network Configuration (NETCONF) Protocol + + The NETCONF Configuration Protocol is specified in one basic + document, with supporting documents for carrying it over the IPS. + These documents include: + + o NETCONF Configuration Protocol [RFC4741] + + o Using the NETCONF Configuration Protocol over Secure SHell (SSH) + [RFC4742] + + o Using NETCONF over the Simple Object Access Protocol (SOAP) + [RFC4743] + + o Using the NETCONF Protocol over the Blocks Extensible Exchange + Protocol (BEEP) [RFC4744] + + o NETCONF Event Notifications [RFC5277] + + o NETCONF over Transport Layer Security (TLS) [RFC5539] + + o Partial Lock Remote Procedure Call (RPC) for NETCONF [RFC5717] + + NETCONF was developed in response to operator requests for a common + configuration protocol based on ASCII text, unlike ASN.1. In + essence, it carries XML-encoded remote procedure call (RPC) data. In + response to Smart Grid requirements, there is consideration of a + variant of the protocol that could be used for polled and event- + driven management activities, and for both monitoring and + configuration of systems in the field. + + + + + +Baker & Meyer Informational [Page 32] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +3.6. Service and Resource Discovery + + Service and resource discovery are among the most important protocols + for constrained resource self-organizing networks. These include + various sensor networks as well as the Home Area Networks (HANs), + Building Area Networks (BANs), and Field Area Networks (FANs) + envisioned by Smart Grid architects. + +3.6.1. Service Discovery + + Service discovery protocols are designed for the automatic + configuration and detection of devices, and the services offered by + the discovered devices. In many cases service discovery is performed + by so-called "constrained resource" devices (i.e., those with limited + processing power, memory, and power resources). + + In general, service discovery is concerned with the resolution and + distribution of host names via multicast DNS [MULTICAST-DNS] and the + automatic location of network services via DHCP (Section 3.4.2), the + DNS Service Discovery (DNS-SD) [DNS-SD] (part of Apple's Bonjour + technology), and the Service Location Protocol (SLP) [RFC2608]. + +3.6.2. Resource Discovery + + Resource Discovery is concerned with the discovery of resources + offered by end-points and is extremely important in machine-to- + machine closed-loop applications (i.e., those with no humans in the + loop). The goals of resource discovery protocols include: + + o Simplicity of creation and maintenance of resources + + o Commonly understood semantics + + o Conformance to existing and emerging standards + + o International scope and applicability + + o Extensibility + + o Interoperability among collections and indexing systems + + The Constrained Application Protocol (CoAP) [COAP] is being developed + in IETF with these goals in mind. In particular, CoAP is designed + for use in constrained resource networks and for machine-to-machine + applications such as smart energy and building automation. It + provides a RESTful transfer protocol [RESTFUL], a built-in resource + discovery protocol, and includes web concepts such as URIs and + content-types. CoAP provides both unicast and multicast resource + + + +Baker & Meyer Informational [Page 33] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + discovery and includes the ability to filter on attributes of + resource descriptions. Finally, CoAP resource discovery can also be + used to discover HTTP resources. + + For simplicity, CoAP makes the assumption that all CoAP servers + listen on the default CoAP port or otherwise have been configured or + discovered using some general service discovery mechanism such as DNS + Service Discovery (DNS-SD) [DNS-SD]. + + Resource discovery in CoAP is accomplished through the use of well- + known resources that describe the links offered by a CoAP server. + CoAP defines a well-known URI for discovery: "/.well-known/r" + [RFC5785]. For example, the query [GET /.well-known/r] returns a + list of links (representing resources) available from the queried + CoAP server. A query such as [GET /.well-known/r?n=Voltage] returns + the resources with the name Voltage. + +3.7. Other Applications + + There are many applications that rely on the IP infrastructure, but + are not properly thought of as part of the IP infrastructure itself. + These applications may be useful in the context of the Smart Grid. + The choices made when constructing a profile of the Internet Profile + Suite may impact how such applications could be used. Some of them, + not by any means an exhaustive list, are discussed here. + +3.7.1. Session Initiation Protocol + + The Session Initiation Protocol [RFC3261] [RFC3265] [RFC3853] + [RFC4320] [RFC4916] [RFC5393] [RFC5621] is an application layer + control (signaling) protocol for creating, modifying, and terminating + multimedia sessions on the Internet, and is meant to be more scalable + than H.323. Multimedia sessions can be voice, video, instant + messaging, shared data, and/or subscriptions of events. SIP can run + on top of TCP, UDP, SCTP, or TLS over TCP. SIP is independent of the + transport layer, and independent of the underlying IPv4/v6 version. + In fact, the transport protocol used can change as the SIP message + traverses SIP entities from source to destination. + + SIP itself does not choose whether a session is voice or video, nor + does it identify the actual endpoints' IP addresses. The Session + Description Protocol (SDP) [RFC4566] is intended for those purposes. + Within the SDP, which is transported by SIP, codecs are offered and + accepted (or not), and the port number and IP address at which each + endpoint wants to receive their Real-time Transport Protocol (RTP) + [RFC3550] packets are determined. The introduction of Network + Address Translation (NAT) technology into the profile, whether IPv4/ + + + + +Baker & Meyer Informational [Page 34] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + IPv4, IPv4/IPv6 as described in Section 3.2.1.3, or IPv6/IPv6, + increases the complexity of SIP/SDP deployment. This is further + discussed in [RFC2993] and [RFC5626]. + +3.7.2. Extensible Messaging and Presence Protocol + + The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is a + protocol for streaming Extensible Markup Language (XML) elements in + order to exchange structured information in close to real time + between any two network endpoints. Since XMPP provides a + generalized, extensible framework for exchanging XML data, it has + been proposed as an application structure for interchange between + embedded devices and sensors. It is currently used for Instant + Messaging and Presence [RFC6121] and a wide variety of real-time + communication modes. These include multi-user chat, publish- + subscribe, alerts and notifications, service discovery, multimedia + session management, device configuration, and remote procedure calls. + XMPP supports channel encryption using TLS [RFC5246] and strong + authentication (including PKIX certificate authentication) using SASL + [RFC4422]. It also makes use of Unicode-compliant addresses and + UTF-8 [RFC3629] data exchange for internationalization. + + XMPP allows for End-to-End Signing and Object Encryption [RFC3923], + access to objects named using Uniform Resource Names (URN) [RFC4854], + use of Internationalized Resource Identifiers (IRIs) and Uniform + Resource Identifiers (URIs) [RFC5122], and the presentation of + Notifications [RFC5437]. + +3.7.3. Calendaring + + Internet calendaring, as implemented in Apple iCal, Microsoft Outlook + and Entourage, and Google Calendar, is specified in Internet + Calendaring and Scheduling Core Object Specification (iCalendar) + [RFC5545] and is in the process of being updated to an XML schema in + iCalendar XML Representation [xCAL]. Several protocols exist to + carry calendar events, including the iCalendar Transport-Independent + Interoperability Protocol (iTIP) [RFC5546], the iCalendar Message- + Based Interoperability Protocol (iMIP) [RFC6047], and open source + work on the Atom Publishing Protocol [RFC5023]. + +4. A Simplified View of the Business Architecture + + The Internet is a network of networks in which networks are + interconnected in specific ways and are independently operated. It + is important to note that the underlying Internet architecture puts + no restrictions on the ways that networks are interconnected; + interconnection is a business decision. As such, the Internet + + + + +Baker & Meyer Informational [Page 35] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + interconnection architecture can be thought of as a "business + structure" for the Internet. + + Central to the Internet business structure are the networks that + provide connectivity to other networks, called "transit networks". + These networks sell bulk bandwidth and routing services to each other + and to other networks as customers. Around the periphery of the + transit network are companies, schools, and other networks that + provide services directly to individuals. These might generally be + divided into "enterprise networks" and "access networks"; enterprise + networks provide "free" connectivity to their own employees or + members, and also provide them a set of services including electronic + mail, web services, and so on. Access networks sell broadband + connectivity (DSL, Cable Modem, 802.11 wireless, or 3GPP wireless) or + "dial" services (including PSTN dial-up and ISDN) to subscribers. + The subscribers are typically either residential or small office/home + office (SOHO) customers. Residential customers are generally + entirely dependent on their access provider for all services, while a + SOHO buys some services from the access provider and may provide + others for itself. Networks that sell transit services to nobody + else -- SOHO, residential, and enterprise networks -- are generally + refereed to as "edge networks"; transit networks are considered to be + part of the "core" of the Internet, and access networks are between + the two. This general structure is depicted in Figure 3. + + ------ ------ + / \ / \ + /--\ / \ / \ + |SOHO|---+ Access | |Enterprise| + \--/ | Service | | Network | + /--\ | Provider| | | + |Home|---+ | ------ | | + \--/ \ +---+ +---+ / + \ / / \ \ / + ------ | Transit | ------ + | Service | + | Provider | + | | + \ / + \ / + ------ + + Figure 3: Conceptual Model of Internet Businesses + + + + + + + + +Baker & Meyer Informational [Page 36] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + A specific example is shown in a traceroute from a home to a nearby + school. Internet connectivity in Figure 4 passes through + + o the home network, + + o Cox Communications, an access network using Cable Modem + technology, + + o TransitRail, a commodity peering service for research and + education (R&E) networks, + + o Corporation for Education Network Initiatives in California + (CENIC), a transit provider for educational networks, and + + o the University of California at Santa Barbara, which in this + context might be viewed as an access network for its students and + faculty or as an enterprise network. + + <stealth-10-32-244-218:> fred% traceroute www.ucsb.edu + traceroute to web.ucsb.edu (128.111.24.41), + 64 hops max, 40 byte packets + 1 fred-vpn (10.32.244.217) 1.560 ms 1.108 ms 1.133 ms + 2 wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1) 12.540 ms ... + 3 68.6.13.101 ... + 4 68.6.13.129 ... + 5 langbbr01-as0.r2.la.cox.net ... + 6 calren46-cust.lsanca01.transitrail.net ... + 7 dc-lax-core1--lax-peer1-ge.cenic.net ... + 8 dc-lax-agg1--lax-core1-ge.cenic.net ... + 9 dc-ucsb--dc-lax-dc2.cenic.net ... + 10 r2--r1--1.commserv.ucsb.edu ... + 11 574-c--r2--2.commserv.ucsb.edu ... + 12 * * * + + Figure 4: Traceroute from Residential Customer to Educational + Institution + + Another specific example could be shown in a traceroute from the home + through a Virtual Private Network (VPN tunnel) from the home, + crossing Cox Cable (an access network) and Pacific Bell (a transit + network), and terminating in Cisco Systems (an enterprise network); a + traceroute of the path doesn't show that as it is invisible within + the VPN and the contents of the VPN are invisible, due to encryption, + to the networks on the path. Instead, the traceroute in Figure 5 is + entirely within Cisco's internal network. + + + + + + +Baker & Meyer Informational [Page 37] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + <stealth-10-32-244-218:~> fred% traceroute irp-view13 + traceroute to irp-view13.cisco.com (171.70.120.60), + 64 hops max, 40 byte packets + 1 fred-vpn (10.32.244.217) 2.560 ms 1.100 ms 1.198 ms + <tunneled path through Cox and Pacific Bell> + 2 **** + 3 sjc24-00a-gw2-ge2-2 (10.34.251.137) 26.298 ms... + 4 sjc23-a5-gw2-g2-1 (10.34.250.78) 25.214 ms ... + 5 sjc20-a5-gw1 (10.32.136.21) 23.205 ms ... + 6 sjc12-abb4-gw1-t2-7 (10.32.0.189) 46.028 ms ... + 7 sjc5-sbb4-gw1-ten8-2 (171.*.*.*) 26.700 ms ... + 8 sjc12-dc5-gw2-ten3-1 ... + 9 sjc5-dc4-gw1-ten8-1 ... + 10 irp-view13 ... + + Figure 5: Traceroute across VPN + + Note that in both cases, the home network uses private address space + [RFC1918] while other networks generally use public address space, + and that three middleware technologies are in use here. These are + the uses of a firewall, a Network Address Translator (NAT), and a + Virtual Private Network (VPN). + + Firewalls are generally sold as and considered by many to be a + security technology. This is based on the fact that a firewall + imposes a border between two administrative domains. Typically, a + firewall will be deployed between a residential, SOHO, or enterprise + network and its access or transit provider. In its essence, a + firewall is a data diode, imposing a policy on what sessions may pass + between a protected domain and the rest of the Internet. Simple + policies generally permit sessions to be originated from the + protected network but not from the outside; more complex policies may + permit additional sessions from the outside, such as electronic mail + to a mail server or a web session to a web server, and may prevent + certain applications from global access even though they are + originated from the inside. + + Note that the effectiveness of firewalls remains controversial. + While network managers often insist on deploying firewalls as they + impose a boundary, others point out that their value as a security + solution is debatable. This is because most attacks come from behind + the firewall. In addition, firewalls do not protect against + application layer attacks such as viruses carried in email. Thus, as + a security solution, firewalls are justified as a layer in defense in + depth. That is, while an end system must in the end be responsible + for its own security, a firewall can inhibit or prevent certain kinds + of attacks, for example the consumption of CPU time on a critical + server. + + + +Baker & Meyer Informational [Page 38] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + Key documents describing firewall technology and the issues it poses + include: + + o IP Multicast and Firewalls [RFC2588] + + o Benchmarking Terminology for Firewall Performance [RFC2647] + + o Behavior of and Requirements for Internet Firewalls [RFC2979] + + o Benchmarking Methodology for Firewall Performance [RFC3511] + + o Mobile IPv6 and Firewalls: Problem Statement [RFC4487] + + o NAT and Firewall Traversal Issues of Host Identity Protocol + Communication [RFC5207] + + Network Address Translation is a technology that was developed in + response to ISP behaviors in the mid-1990's; when [RFC1918] was + published, many ISPs started handing out single or small numbers of + addresses, and edge networks were forced to translate. In time, this + became considered a good thing, or at least not a bad thing; it + amplified the public address space, and it was sold as if it were a + firewall. It of course is not; while traditional dynamic NATs only + translate between internal and external session address/port tuples + during the detected duration of the session, that session state may + exist in the network much longer than it exists on the end system, + and as a result constitutes an attack vector. The design, value, and + limitations of network address translation are described in: + + o IP Network Address Translator Terminology and Considerations + [RFC2663] + + o Traditional IP Network Address Translator [RFC3022] + + o Protocol Complications with the IP Network Address Translator + [RFC3027] + + o Network Address Translator Friendly Application Design Guidelines + [RFC3235] + + o IAB Considerations for Network Address Translation [RFC3424] + + o IPsec-Network Address Translation Compatibility Requirements + [RFC3715] + + o Network Address Translation Behavioral Requirements for Unicast + UDP [RFC4787] + + + + +Baker & Meyer Informational [Page 39] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + o State of Peer-to-Peer Communication across Network Address + Translators [RFC5128] + + o IP Multicast Requirements for a Network Address Translator and a + Network Address Port Translator [RFC5135] + + Virtual Private Networks come in many forms; what they have in common + is that they are generally tunneled over the Internet backbone, so + that as in Figure 5, connectivity appears to be entirely within the + edge network although it is in fact across a service provider's + network. Examples include IPsec tunnel-mode encrypted tunnels, IP- + in-IP or GRE tunnels, and MPLS LSPs [RFC3031][RFC3032]. + +5. Security Considerations + + Security is addressed in some detail in Section 2.2 and Section 3.1. + +6. Acknowledgements + + Review comments were made by Adrian Farrel, Andrew Yourtchenko, Ashok + Narayanan, Bernie Volz, Chris Lonvick, Dan Romascanu, Dave McGrew, + Dave Oran, David Harrington, David Su, Don Sturek, Francis Cleveland, + Hemant Singh, James Polk, Jari Arkko, John Meylor, Joseph Salowey, + Julien Abeille, Kerry Lynn, Lars Eggert, Magnus Westerlund, Murtaza + Chiba, Paul Duffy, Paul Hoffman, Peter Saint-Andre, Ralph Droms, + Robert Sparks, Russ White, Sean Turner, Sheila Frankel, Stephen + Farrell, Tim Polk, Toerless Eckert, Tom Herbst, Vint Cerf, and + Yoshihiro Ohba. Several of the individuals suggested text, which was + very useful, as the authors don't claim to know half as much as their + reviewers collectively do. + +7. References + +7.1. Normative References + + [RFC1122] Braden, R., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, + October 1989. + + [RFC1123] Braden, R., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, + October 1989. + + [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", + RFC 1812, June 1995. + + [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, + April 2006. + + + +Baker & Meyer Informational [Page 40] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +7.2. Informative References + + [6LOWPAN-HC] Hui, J. and P. Thubert, "Compression Format for IPv6 + Datagrams in Low Power and Lossy Networks + (6LoWPAN)", Work in Progress, February 2011. + + [ABFAB-ARCH] Howlett, J., Hartman, S., Tschofenig, H., and E. + Lear, "Application Bridging for Federated Access + Beyond Web (ABFAB) Architecture", Work in Progress, + March 2011. + + [AES-CCM-ECC] McGrew, D., Bailey, D., Campagna, M., and R. Dugal, + "AES-CCM ECC Cipher Suites for TLS", Work + in Progress, January 2011. + + [COAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, + "Constrained Application Protocol (CoAP)", Work + in Progress, March 2011. + + [DIME-BASE] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. + Zorn, "Diameter Base Protocol", Work in Progress, + January 2011. + + [DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", Work in Progress, February 2011. + + [DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport + Layer Security version 1.2", Work in Progress, + March 2011. + + [DYMO] Chakeres, I. and C. Perkins, "Dynamic MANET On- + demand (DYMO) Routing", Work in Progress, July 2010. + + [IEC61850] Wikipedia, "Wikipedia Article: IEC 61850", + June 2011, <http://en.wikipedia.org/w/ + index.php?title=IEC_61850&oldid=433437827>. + + [IEC62351-3] International Electrotechnical Commission Technical + Committee 57, "POWER SYSTEMS MANAGEMENT AND + ASSOCIATED INFORMATION EXCHANGE. DATA AND + COMMUNICATIONS SECURITY -- Part 3: Communication + network and system security Profiles including + TCP/IP", May 2007. + + [IEEE802.1X] Institute of Electrical and Electronics Engineers, + "IEEE Standard for Local and Metropolitan Area + Networks - Port based Network Access Control", + IEEE Standard 802.1X-2010, February 2010. + + + +Baker & Meyer Informational [Page 41] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [IP-SEC] Gont, F., "Security Assessment of the Internet + Protocol Version 4", Work in Progress, April 2011. + + [IPv6-NODE-REQ] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 + Node Requirements", Work in Progress, May 2011. + + [MULTICAST-DNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work + in Progress, February 2011. + + [Model] SGIP, "Smart Grid Architecture Committee: Conceptual + Model White Paper http://collaborate.nist.gov/ + twiki-sggrid/pub/SmartGrid/ + SGIPConceptualModelDevelopmentSGAC/ + Smart_Grid_Conceptual_Model_20100420.doc". + + [OAUTHv2] Hammer-Lahav, E., Recordon, D., and D. Hardt, "The + OAuth 2.0 Authorization Protocol", Work in Progress, + May 2011. + + [RESTFUL] Fielding, "Architectural Styles and the Design of + Network-based Software Architectures", 2000. + + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, + RFC 768, August 1980. + + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC0792] Postel, J., "Internet Control Message Protocol", + STD 5, RFC 792, September 1981. + + [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: + Or converting network protocol addresses to 48.bit + Ethernet address for transmission on Ethernet + hardware", STD 37, RFC 826, November 1982. + + [RFC0894] Hornig, C., "Standard for the transmission of IP + datagrams over Ethernet networks", STD 41, RFC 894, + April 1984. + + [RFC1006] Rose, M. and D. Cass, "ISO transport services on top + of the TCP: Version 3", STD 35, RFC 1006, May 1987. + + [RFC1034] Mockapetris, P., "Domain names - concepts and + facilities", STD 13, RFC 1034, November 1987. + + + +Baker & Meyer Informational [Page 42] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1058] Hedrick, C., "Routing Information Protocol", + RFC 1058, June 1988. + + [RFC1112] Deering, S., "Host extensions for IP multicasting", + STD 5, RFC 1112, August 1989. + + [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP + and dual environments", RFC 1195, December 1990. + + [RFC1332] McGregor, G., "The PPP Internet Protocol Control + Protocol (IPCP)", RFC 1332, May 1992. + + [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", + STD 51, RFC 1661, July 1994. + + [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, + G., and E. Lear, "Address Allocation for Private + Internets", BCP 5, RFC 1918, February 1996. + + [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API + Mechanism", RFC 1964, June 1996. + + [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", + RFC 2080, January 1997. + + [RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on + top of TCP (ITOT)", RFC 2126, March 1997. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. + + [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, + "Dynamic Updates in the Domain Name System (DNS + UPDATE)", RFC 2136, April 1997. + + [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, + April 1998. + + [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, + "IETF Criteria for Evaluating Reliable Multicast + Transport and Application Protocols", RFC 2357, + June 1998. + + [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, + November 1998. + + + +Baker & Meyer Informational [Page 43] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, + Version 6 (IPv6) Specification", RFC 2460, + December 1998. + + [RFC2464] Crawford, M., "Transmission of IPv6 Packets over + Ethernet Networks", RFC 2464, December 1998. + + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, + December 1998. + + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, + Z., and W. Weiss, "An Architecture for + Differentiated Services", RFC 2475, December 1998. + + [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., + Simone, D., and R. Wheeler, "A Method for + Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, + February 1999. + + [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 + Multiprotocol Extensions for IPv6 Inter-Domain + Routing", RFC 2545, March 1999. + + [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., + and C. Adams, "X.509 Internet Public Key + Infrastructure Online Certificate Status Protocol - + OCSP", RFC 2560, June 1999. + + [RFC2588] Finlayson, R., "IP Multicast and Firewalls", + RFC 2588, May 1999. + + [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, + "Service Location Protocol, Version 2", RFC 2608, + June 1999. + + [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", + RFC 2615, June 1999. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, + "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, + June 1999. + + [RFC2647] Newman, D., "Benchmarking Terminology for Firewall + Performance", RFC 2647, August 1999. + + + + +Baker & Meyer Informational [Page 44] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address + Translator (NAT) Terminology and Considerations", + RFC 2663, August 1999. + + [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, + October 1999. + + [RFC2743] Linn, J., "Generic Security Service Application + Program Interface Version 2, Update 1", RFC 2743, + January 2000. + + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. + Traina, "Generic Routing Encapsulation (GRE)", + RFC 2784, March 2000. + + [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, + "Remote Authentication Dial In User Service + (RADIUS)", RFC 2865, June 2000. + + [RFC2979] Freed, N., "Behavior of and Requirements for + Internet Firewalls", RFC 2979, October 2000. + + [RFC2993] Hain, T., "Architectural Implications of NAT", + RFC 2993, November 2000. + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) + Dynamic Update", RFC 3007, November 2000. + + [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP + Network Address Translator (Traditional NAT)", + RFC 3022, January 2001. + + [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol + Complications with the IP Network Address + Translator", RFC 3027, January 2001. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, + "Multiprotocol Label Switching Architecture", + RFC 3031, January 2001. + + [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., + Farinacci, D., Li, T., and A. Conta, "MPLS Label + Stack Encoding", RFC 3032, January 2001. + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The + Addition of Explicit Congestion Notification (ECN) + to IP", RFC 3168, September 2001. + + + +Baker & Meyer Informational [Page 45] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC3235] Senie, D., "Network Address Translator (NAT)- + Friendly Application Design Guidelines", RFC 3235, + January 2002. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., + Johnston, A., Peterson, J., Sparks, R., Handley, M., + and E. Schooler, "SIP: Session Initiation Protocol", + RFC 3261, June 2002. + + [RFC3265] Roach, A., "Session Initiation Protocol (SIP)- + Specific Event Notification", RFC 3265, June 2002. + + [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible + Markup Language) XML-Signature Syntax and + Processing", RFC 3275, March 2002. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration + Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and + A. Thyagarajan, "Internet Group Management Protocol, + Version 3", RFC 3376, October 2002. + + [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An + Architecture for Describing Simple Network + Management Protocol (SNMP) Management Frameworks", + STD 62, RFC 3411, December 2002. + + [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. + Wijnen, "Message Processing and Dispatching for the + Simple Network Management Protocol (SNMP)", STD 62, + RFC 3412, December 2002. + + [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network + Management Protocol (SNMP) Applications", STD 62, + RFC 3413, December 2002. + + [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security + Model (USM) for version 3 of the Simple Network + Management Protocol (SNMPv3)", STD 62, RFC 3414, + December 2002. + + [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View- + based Access Control Model (VACM) for the Simple + Network Management Protocol (SNMP)", STD 62, + RFC 3415, December 2002. + + + + +Baker & Meyer Informational [Page 46] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations + for the Simple Network Management Protocol (SNMP)", + STD 62, RFC 3416, December 2002. + + [RFC3417] Presuhn, R., "Transport Mappings for the Simple + Network Management Protocol (SNMP)", STD 62, + RFC 3417, December 2002. + + [RFC3418] Presuhn, R., "Management Information Base (MIB) for + the Simple Network Management Protocol (SNMP)", + STD 62, RFC 3418, December 2002. + + [RFC3424] Daigle, L. and IAB, "IAB Considerations for + UNilateral Self-Address Fixing (UNSAF) Across + Network Address Translation", RFC 3424, + November 2002. + + [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, + "Transport Layer Security over Stream Control + Transmission Protocol", RFC 3436, December 2002. + + [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., + Handley, M., and J. Crowcroft, "The Use of Forward + Error Correction (FEC) in Reliable Multicast", + RFC 3453, December 2002. + + [RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. + Martin, "Benchmarking Methodology for Firewall + Performance", RFC 3511, April 2003. + + [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. + Jacobson, "RTP: A Transport Protocol for Real-Time + Applications", STD 64, RFC 3550, July 2003. + + [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing + RFC Text on Security Considerations", BCP 72, + RFC 3552, July 2003. + + [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc + On-Demand Distance Vector (AODV) Routing", RFC 3561, + July 2003. + + [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific + Multicast (SSM)", RFC 3569, July 2003. + + [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., + and J. Arkko, "Diameter Base Protocol", RFC 3588, + September 2003. + + + +Baker & Meyer Informational [Page 47] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC3590] Haberman, B., "Source Address Selection for the + Multicast Listener Discovery (MLD) Protocol", + RFC 3590, September 2003. + + [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State + Routing Protocol (OLSR)", RFC 3626, October 2003. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address + Translation (NAT) Compatibility Requirements", + RFC 3715, March 2004. + + [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery + Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. + + [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, + L-E., and G. Fairhurst, "The Lightweight User + Datagram Protocol (UDP-Lite)", RFC 3828, July 2004. + + [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard + (AES) Requirement for the Session Initiation + Protocol (SIP)", RFC 3853, July 2004. + + [RFC3923] Saint-Andre, P., "End-to-End Signing and Object + Encryption for the Extensible Messaging and Presence + Protocol (XMPP)", RFC 3923, October 2004. + + [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, + March 2005. + + [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol + Independent Multicast - Dense Mode (PIM-DM): + Protocol Specification (Revised)", RFC 3973, + January 2005. + + [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible + Authentication Protocol (EAP) Method Requirements + for Wireless LANs", RFC 4017, March 2005. + + [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "DNS Security Introduction and + Requirements", RFC 4033, March 2005. + + + + + + +Baker & Meyer Informational [Page 48] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Resource Records for the DNS Security + Extensions", RFC 4034, March 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and + S. Rose, "Protocol Modifications for the DNS + Security Extensions", RFC 4035, March 2005. + + [RFC4108] Housley, R., "Using Cryptographic Message Syntax + (CMS) to Protect Firmware Packages", RFC 4108, + August 2005. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, + "The Kerberos Network Authentication Service (V5)", + RFC 4120, July 2005. + + [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The + Kerberos Version 5 Generic Security Service + Application Program Interface (GSS-API) Mechanism: + Version 2", RFC 4121, July 2005. + + [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, + "Internet X.509 Public Key Infrastructure + Certificate Management Protocol (CMP)", RFC 4210, + September 2005. + + [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition + Mechanisms for IPv6 Hosts and Routers", RFC 4213, + October 2005. + + [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) + Transport Layer Protocol", RFC 4253, January 2006. + + [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway + Protocol 4 (BGP-4)", RFC 4271, January 2006. + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, + December 2005. + + [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", + RFC 4303, December 2005. + + + + +Baker & Meyer Informational [Page 49] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in + the Internet Key Exchange Version 2 (IKEv2)", + RFC 4307, December 2005. + + [RFC4320] Sparks, R., "Actions Addressing Identified Issues + with the Session Initiation Protocol's (SIP) Non- + INVITE Transaction", RFC 4320, January 2006. + + [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram + Congestion Control Protocol (DCCP)", RFC 4340, + March 2006. + + [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport + Layer Security", RFC 4347, April 2006. + + [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual + Private Networks (VPNs)", RFC 4364, February 2006. + + [RFC4410] Pullen, M., Zhao, F., and D. Cohen, "Selectively + Reliable Multicast Protocol (SRMP)", RFC 4410, + February 2006. + + [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication + and Security Layer (SASL)", RFC 4422, June 2006. + + [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet + Control Message Protocol (ICMPv6) for the Internet + Protocol Version 6 (IPv6) Specification", RFC 4443, + March 2006. + + [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, + "Mobile IPv6 and Firewalls: Problem Statement", + RFC 4487, May 2006. + + [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., + and B. Moeller, "Elliptic Curve Cryptography (ECC) + Cipher Suites for Transport Layer Security (TLS)", + RFC 4492, May 2006. + + [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for + Initial Authentication in Kerberos (PKINIT)", + RFC 4556, June 2006. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: + Session Description Protocol", RFC 4566, July 2006. + + + + + + +Baker & Meyer Informational [Page 50] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration + Guidelines for DiffServ Service Classes", RFC 4594, + August 2006. + + [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. + Kouvelas, "Protocol Independent Multicast - Sparse + Mode (PIM-SM): Protocol Specification (Revised)", + RFC 4601, August 2006. + + [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using + Internet Group Management Protocol Version 3 + (IGMPv3) and Multicast Listener Discovery Protocol + Version 2 (MLDv2) for Source-Specific Multicast", + RFC 4604, August 2006. + + [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast + for IP", RFC 4607, August 2006. + + [RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source- + Specific Protocol Independent Multicast in 232/8", + BCP 120, RFC 4608, August 2006. + + [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A + Roadmap for Transmission Control Protocol (TCP) + Specification Documents", RFC 4614, September 2006. + + [RFC4741] Enns, R., "NETCONF Configuration Protocol", + RFC 4741, December 2006. + + [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF + Configuration Protocol over Secure SHell (SSH)", + RFC 4742, December 2006. + + [RFC4743] Goddard, T., "Using NETCONF over the Simple Object + Access Protocol (SOAP)", RFC 4743, December 2006. + + [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol + over the Blocks Extensible Exchange Protocol + (BEEP)", RFC 4744, December 2006. + + [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, + "Multiprotocol Extensions for BGP-4", RFC 4760, + January 2007. + + [RFC4787] Audet, F. and C. Jennings, "Network Address + Translation (NAT) Behavioral Requirements for + Unicast UDP", BCP 127, RFC 4787, January 2007. + + + + +Baker & Meyer Informational [Page 51] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC4835] Manral, V., "Cryptographic Algorithm Implementation + Requirements for Encapsulating Security Payload + (ESP) and Authentication Header (AH)", RFC 4835, + April 2007. + + [RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) + Namespace for Extensions to the Extensible Messaging + and Presence Protocol (XMPP)", RFC 4854, + April 2007. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. + Soliman, "Neighbor Discovery for IP version 6 + (IPv6)", RFC 4861, September 2007. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 + Stateless Address Autoconfiguration", RFC 4862, + September 2007. + + [RFC4916] Elwell, J., "Connected Identity in the Session + Initiation Protocol (SIP)", RFC 4916, June 2007. + + [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, + "IPv6 over Low-Power Wireless Personal Area Networks + (6LoWPANs): Overview, Assumptions, Problem + Statement, and Goals", RFC 4919, August 2007. + + [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy + Extensions for Stateless Address Autoconfiguration + in IPv6", RFC 4941, September 2007. + + [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. + Culler, "Transmission of IPv6 Packets over IEEE + 802.15.4 Networks", RFC 4944, September 2007. + + [RFC4960] Stewart, R., "Stream Control Transmission Protocol", + RFC 4960, September 2007. + + [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common + Mitigations", RFC 4987, August 2007. + + [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing + Protocol", RFC 5023, October 2007. + + [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and + M. Kozuka, "Stream Control Transmission Protocol + (SCTP) Dynamic Address Reconfiguration", RFC 5061, + September 2007. + + + + +Baker & Meyer Informational [Page 52] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP + Version 6 over PPP", RFC 5072, September 2007. + + [RFC5122] Saint-Andre, P., "Internationalized Resource + Identifiers (IRIs) and Uniform Resource Identifiers + (URIs) for the Extensible Messaging and Presence + Protocol (XMPP)", RFC 5122, February 2008. + + [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of + Peer-to-Peer (P2P) Communication across Network + Address Translators (NATs)", RFC 5128, March 2008. + + [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements + for a Network Address Translator (NAT) and a Network + Address Port Translator (NAPT)", BCP 135, RFC 5135, + February 2008. + + [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., + and A. Yegin, "Protocol for Carrying Authentication + for Network Access (PANA)", RFC 5191, May 2008. + + [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT + and Firewall Traversal Issues of Host Identity + Protocol (HIP) Communication", RFC 5207, April 2008. + + [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS + Authentication Protocol", RFC 5216, March 2008. + + [RFC5238] Phelan, T., "Datagram Transport Layer Security + (DTLS) over the Datagram Congestion Control Protocol + (DCCP)", RFC 5238, May 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer + Security (TLS) Protocol Version 1.2", RFC 5246, + August 2008. + + [RFC5272] Schaad, J. and M. Myers, "Certificate Management + over CMS (CMC)", RFC 5272, June 2008. + + [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event + Notifications", RFC 5277, July 2008. + + [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., + Housley, R., and W. Polk, "Internet X.509 Public Key + Infrastructure Certificate and Certificate + Revocation List (CRL) Profile", RFC 5280, May 2008. + + + + + +Baker & Meyer Informational [Page 53] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with + SHA-256/384 and AES Galois Counter Mode (GCM)", + RFC 5289, August 2008. + + [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, + October 2008. + + [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, + "OSPF for IPv6", RFC 5340, July 2008. + + [RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. + Campen, "Addressing an Amplification Vulnerability + in Session Initiation Protocol (SIP) Forking + Proxies", RFC 5393, December 2008. + + [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage + Guidelines for Application Designers", BCP 145, + RFC 5405, November 2008. + + [RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B + Profile for Transport Layer Security (TLS)", + RFC 5430, March 2009. + + [RFC5433] Clancy, T. and H. Tschofenig, "Extensible + Authentication Protocol - Generalized Pre-Shared Key + (EAP-GPSK) Method", RFC 5433, February 2009. + + [RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification + Mechanism: Extensible Messaging and Presence + Protocol (XMPP)", RFC 5437, January 2009. + + [RFC5539] Badra, M., "NETCONF over Transport Layer Security + (TLS)", RFC 5539, May 2009. + + [RFC5545] Desruisseaux, B., "Internet Calendaring and + Scheduling Core Object Specification (iCalendar)", + RFC 5545, September 2009. + + [RFC5546] Daboo, C., "iCalendar Transport-Independent + Interoperability Protocol (iTIP)", RFC 5546, + December 2009. + + [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. + Barthel, "Routing Requirements for Urban Low-Power + and Lossy Networks", RFC 5548, May 2009. + + [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 + Infrastructures (6rd)", RFC 5569, January 2010. + + + +Baker & Meyer Informational [Page 54] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC5621] Camarillo, G., "Message Body Handling in the Session + Initiation Protocol (SIP)", RFC 5621, + September 2009. + + [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing + Client-Initiated Connections in the Session + Initiation Protocol (SIP)", RFC 5626, October 2009. + + [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", + STD 70, RFC 5652, September 2009. + + [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, + "Industrial Routing Requirements in Low-Power and + Lossy Networks", RFC 5673, October 2009. + + [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP + Congestion Control", RFC 5681, September 2009. + + [RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote + Procedure Call (RPC) for NETCONF", RFC 5717, + December 2009. + + [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. + Macker, "NACK-Oriented Reliable Multicast (NORM) + Transport Protocol", RFC 5740, November 2009. + + [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose + Internet Mail Extensions (S/MIME) Version 3.2 + Message Specification", RFC 5751, January 2010. + + [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well- + Known Uniform Resource Identifiers (URIs)", + RFC 5785, April 2010. + + [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home + Automation Routing Requirements in Low-Power and + Lossy Networks", RFC 5826, April 2010. + + [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and + R. Aggarwal, "Support of Address Families in + OSPFv3", RFC 5838, April 2010. + + [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", + RFC 5849, April 2010. + + + + + + + +Baker & Meyer Informational [Page 55] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. + Vermeylen, "Building Automation Routing Requirements + in Low-Power and Lossy Networks", RFC 5867, + June 2010. + + [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, + "Network Time Protocol Version 4: Protocol and + Algorithms Specification", RFC 5905, June 2010. + + [RFC5932] Kato, A., Kanda, M., and S. Kanno, "Camellia Cipher + Suites for TLS", RFC 5932, June 2010. + + [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, + August 2010. + + [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, + "Internet Key Exchange Protocol Version 2 (IKEv2)", + RFC 5996, September 2010. + + [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An + Extension for EAP-Only Authentication in IKEv2", + RFC 5998, September 2010. + + [RFC6031] Turner, S. and R. Housley, "Cryptographic Message + Syntax (CMS) Symmetric Key Package Content Type", + RFC 6031, December 2010. + + [RFC6047] Melnikov, A., "iCalendar Message-Based + Interoperability Protocol (iMIP)", RFC 6047, + December 2010. + + [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., + and X. Li, "IPv6 Addressing of IPv4/IPv6 + Translators", RFC 6052, October 2010. + + [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental + Elliptic Curve Cryptography Algorithms", RFC 6090, + February 2011. + + [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Core", RFC 6120, March 2011. + + [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence + Protocol (XMPP): Instant Messaging and Presence", + RFC 6121, March 2011. + + [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework + for IPv4/IPv6 Translation", RFC RFC6144, April 2011. + + + +Baker & Meyer Informational [Page 56] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation + Algorithm", RFC 6145, April 2011. + + [RFC6146] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful + NAT64: Network Address and Protocol Translation from + IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. + + [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. + Beijnum, "DNS64: DNS Extensions for Network Address + Translation from IPv6 Clients to IPv4 Servers", + RFC 6147, April 2011. + + [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 + Transition Mechanisms during IPv6 Deployment", + RFC 6180, May 2011. + + + [RPL] Winter, T., Thubert, P., Brandt, A., Clausen, T., + Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, + R., and J. Vasseur, "RPL: IPv6 Routing Protocol for + Low power and Lossy Networks", Work in Progress, + March 2011. + + [SP-MULPIv3.0] CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols + Interface Specification, CM-SP-MULPIv3.0-I10- + 090529", May 2009. + + [SmartGrid] Wikipedia, "Wikipedia Article: Smart Grid", + February 2011, <http://en.wikipedia.org/w/ + index.php?title=Smart_grid&oldid=415838933>. + + [TCP-SEC] Gont, F., "Security Assessment of the Transmission + Control Protocol (TCP)", Work in Progress, + January 2011. + + [r1822] Bolt Beranek and Newman Inc., "Interface Message + Processor -- Specifications for the interconnection + of a host and a IMP, Report No. 1822", January 1976. + + [xCAL] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML + format for iCalendar", Work in Progress, April 2011. + + + + + + + + + + +Baker & Meyer Informational [Page 57] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +Appendix A. Example: Advanced Metering Infrastructure + + This appendix provides a worked example of the use of the Internet + Protocol Suite in a network such as the Smart Grid's Advanced + Metering Infrastructure (AMI). There are several possible models. + + Figure 6 shows the structure of the AMI as it reaches out towards a + set of residences. In this structure, we have the home itself and + its Home Area Network (HAN), the Neighborhood Area Network (NAN) that + the utility uses to access the meter at the home, and the utility + access network that connects a set of NANs to the utility itself. + For the purposes of this discussion, assume that the NAN contains a + distributed application in a set collectors, which is of course only + one way the application could be implemented. + + --- + A thermostats, appliances, etc + | ------+----------------------------------- + | | + |"HAN" | <--- Energy Services Interface (ESI) + | +---+---+ + | | Meter | Meter is generally an ALG between the AMI and the HAN + | +---+---+ + V \ + --- \ + A \ | / + | \ | / + | "NAN" +--+-+-+---+ Likely a router but could + | |Collector | be a front-end application + V +----+-----+ gateway for utility + --- \ + A \ | / + | \ | / + |"AMI" +--+-+-+--+ + | | AMI | + | | Headend | + V +---------+ + --- + + Figure 6: The HAN, NAN, and Utility in the Advanced Metering + Infrastructure + + There are several questions that have to be answered in describing + this picture, which given possible answers yield different possible + models. They include at least: + + o How does Demand Response work? Either: + + + + +Baker & Meyer Informational [Page 58] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + * The utility presents pricing signals to the home, + + * The utility presents pricing signals to individual devices + (e.g., a Pluggable Electric Vehicle), + + * The utility adjusts settings on individual appliances within + the home. + + o How does the utility access meters at the home? + + * The AMI Headend manages the interfaces with the meters, + collecting metering data and passing it on to the appropriate + applications over the Enterprise Bus, or + + * Distributed application support ("collectors") might access and + summarize the information; this device might be managed by the + utility or by a service between the utility and its customers. + + In implementation, these models are idealized; reality may include + some aspects of each model in specified cases. + + The examples include: + + 1. Appendix A.2 presumes that the HAN, the NAN, and the utility's + network are separate administrative domains and speak application + to application across those domains. + + 2. Appendix A.3 repeats the first example, but presuming that the + utility directly accesses appliances within the HAN from the + collector. + + 3. Appendix A.4 repeats the first example, but presuming that the + collector directly forwards traffic as a router in addition to + distributed application chores. Note that this case implies + numerous privacy and security concerns and as such is considered + a less likely deployment model. + +A.1. How to Structure a Network + + A key consideration in the Internet has been the development of new + link layer technologies over time. The ARPANET originally used a BBN + proprietary link layer called BBN 1822 [r1822]. In the late 1970's, + the ARPANET switched to X.25 as an interface to the 1822 network. + With the deployment of the IEEE 802 series technologies in the early + 1980's, IP was deployed on Ethernet (IEEE 802.3), Token Ring (IEEE + 802.5) and WiFi (IEEE 802.11), as well as Arcnet, serial lines of + various kinds, Frame Relay, and ATM. A key issue in this evolution + was that the applications developed to run on the Internet use APIs + + + +Baker & Meyer Informational [Page 59] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + related to the IPS, and as a result require little or no change to + continue operating in a new link layer architecture or a mixture of + them. + + The Smart Grid is likely to see a similar evolution over time. + Consider the Home Area Network (HAN) as a readily understandable + small network. At this juncture, technologies proposed for + residential networks include IEEE P1901, various versions of IEEE + 802.15.4, and IEEE 802.11. It is reasonable to expect other + technologies to be developed in the future. As the Zigbee Alliance + has learned (and as a resulted incorporated the IPS in Smart Energy + Profile 2.0), there is significant value in providing a virtual + address that is mapped to interfaces or nodes attached to each of + those technologies. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Baker & Meyer Informational [Page 60] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + Utility NAN + / + / + +----+-----+ +--+ +--+ +--+ + | Meter | |D1| |D2| |D3| + +-----+----+ ++-+ ++-+ ++-+ + | | | | + ----+-+-------+----+----+---- IEEE 802.15.4 + | + +--+---+ + |Router+------/------ Residential Broadband + +--+---+ + | + ----+---------+----+----+---- IEEE P1901 + | | | + ++-+ ++-+ ++-+ + |D4| |D5| |D6| + +--+ +--+ +--+ + A thermostats, appliances, etc + | ------+----------------+------------------ + |"HAN" | | + | +---+---+ +---+---+ + | |Router | | Meter | + | |or EMS | | | + V +---+---+ +---+---+ + --- | --- \ + | ^ \ | / + | |"NAN" \ | / + ---+--- | +--+-+-+---+ + / \ | |"Pole Top"| + | Internet| v +----+-----+ + \ / --- + ------- + + Figure 7: Two Views of a Home Area Network + + There are two possible communication models within the HAN, both of + which are likely to be useful. Devices may communicate directly with + each other, or they may be managed by some central controller. An + example of direct communications might be a light switch that + directly commands a lamp to turn on or off. An example of indirect + communications might be a control application in a Customer or + Building that accepts telemetry from a thermostat, applies some form + of policy, and controls the heating and air conditioning systems. In + addition, there are high-end appliances in the market today that use + residential broadband to communicate with their manufacturers, and + obviously the meter needs to communicate with the utility. + + + + +Baker & Meyer Informational [Page 61] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + Figure 7 shows two simple networks, one of which uses IEEE 802.15.4 + and IEEE 1901 domains, and one of which uses an arbitrary LAN within + the home, which could be IEEE 802.3/Ethernet, IEEE 802.15.4, IEEE + 1901, IEEE 802.11, or anything else that made sense in context. Both + show the connectivity between them as a router separate from the + energy management system (EMS). This is for clarity; the two could + of course be incorporated into a single system, and one could imagine + appliances that want to communicate with their manufacturers + supporting both a HAN interface and a WiFi interface rather than + depending on the router. These are all manufacturer design + decisions. + +A.1.1. HAN Routing + + The HAN can be seen as communicating with two kinds of non-HAN + networks. One is the home LAN, which may in turn be attached to the + Internet, and will generally either derive its prefix from the + upstream ISP or use a self-generated Unique Local Addressing (ULA). + Another is the utility's NAN, which through an ESI provides utility + connectivity to the HAN; in this case the HAN will be addressed by a + self-generated ULA (note, however, that in some cases ESI may also + provide a prefix via DHCP [RFC3315]). In addition, the HAN will have + link-local addresses that can be used between neighboring nodes. In + general, an HAN will be comprised of both 802.15.4, 802.11, and + possibly other networks. + + The ESI is a node on the user's residential network, and will not + typically provide stateful packet forwarding or firewall services + between the HAN and the utility network(s). In general, the ESI is a + node on the home network; in some cases, the meter may act as the + ESI. However, the ESI must be capable of understanding that most + home networks are not 802.15.4 enabled (rather, they are typically + 802.11 networks), and that it must be capable of setting up ad hoc + networks between various sensors in the home (e.g., between the meter + and say, a thermostat) in the event there aren't other networks + available. + +A.1.2. HAN Security + + In any network, we have a variety of threats and a variety of + possible mitigations. These include, at minimum: + + Link Layer: Why is your machine able to talk in my network? The + WiFi SSIDs often use some form of authenticated access control, + which may be a simple encrypted password mechanism or may use a + combination of encryption and IEEE 802.1X+EAP-TLS Authentication/ + + + + + +Baker & Meyer Informational [Page 62] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + Authorization to ensure that only authorized communicants can use + it. If a LAN has a router attached, the router may also implement + a firewall to filter remote accesses. + + Network Layer: Given that your machine is authorized access to my + network, why is your machine talking with my machine? IPsec is a + way of ensuring that computers that can use a network are allowed + to talk with each other, may also enforce confidentiality, and may + provide VPN services to make a device or network appear to be part + of a remote network. + + Application: Given that your machine is authorized access to my + network and my machine, why is your application talking with my + application? The fact that your machine and mine are allowed to + talk for some applications doesn't mean they are allowed to for + all applications. (D)TLS, https, and other such mechanisms enable + an application to impose application-to-application controls + similar to the network layer controls provided by IPsec. + + Remote Application: How do I know that the data I received is the + data you sent? Especially in applications like electronic mail, + where data passes through a number of intermediaries that one may + or may not really want munging it (how many times have you seen a + URL broken by a mail server?), we have tools (DKIM, S/MIME, and + W3C XML Signatures to name a few) to provide non-repudiability and + integrity verification. This may also have legal ramifications: + if a record of a meter reading is to be used in billing, and the + bill is disputed in court, one could imagine the court wanting + proof that the record in fact came from that meter at that time + and contained that data. + + Application-specific security: In addition, applications often + provide security services of their own. The fact that I can + access a file system, for example, doesn't mean that I am + authorized to access everything in it; the file system may well + prevent my access to some of its contents. Routing protocols like + BGP are obsessed with the question "what statements that my peer + made am I willing to believe", and monitoring protocols like SNMP + may not be willing to answer every question they are asked, + depending on access configuration. + + Devices in the HAN want controlled access to the LAN in question for + obvious reasons. In addition, there should be some form of mutual + authentication between devices -- the lamp controller will want to + know that the light switch telling it to change state is the right + light switch, for example. The EMS may well want strong + authentication of accesses -- the parents may not want the children + + + + +Baker & Meyer Informational [Page 63] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + changing the settings, and while the utility and the customer are + routinely granted access, other parties (especially parties with + criminal intent) need to be excluded. + +A.2. Model 1: AMI with Separated Domains + + With the background given in Appendix A.1, we can now discuss the use + of IP (IPv4 or IPv6) in the AMI. + + In this first model, consider the three domains in Figure 6 to + literally be separate administrative domains, potentially operated by + different entities. For example, the NAN could be a WiMAX network + operated by a traditional telecom operator, the utility's network + (including the collector) is its own, and the residential network is + operated by the resident. In this model, while communications + between the collector and the Meter are normal, the utility has no + other access to appliances in the home, and the collector doesn't + directly forward messages from the NAN upstream. + + In this case, as shown in Figure 7, it would make the most sense to + design the collector, the Meter, and the EMS as hosts on the NAN -- + design them as systems whose applications can originate and terminate + exchanges or sessions in the NAN, but not forward traffic from or to + other devices. + + In such a configuration, Demand Response has to be performed by + having the EMS accept messages such as price signals from the "pole + top", apply some form of policy, and then orchestrate actions within + the home. Another possibility is to have the EMS communicate with + the ESI located in the meter. If the thermostat has high demand and + low demand (day/night or morning/day/evening/night) settings, Demand + Response might result in it moving to a lower demand setting, and the + EMS might also turn off specified circuits in the home to diminish + lighting. + + In this scenario, Quality of Service (QoS) issues reportedly arise + when high precedence messages must be sent through the collector to + the home; if the collector is occupied polling the meters or doing + some other task, the application may not yield control of the + processor to the application that services the message. Clearly, + this is either an application or an Operating System problem; + applications need to be designed in a manner that doesn't block high + precedence messages. The collector also needs to use appropriate NAN + services, if they exist, to provide the NAN QoS it needs. For + example, if WiMax is in use, it might use a routine-level service for + normal exchanges but a higher precedence service for these messages. + + + + + +Baker & Meyer Informational [Page 64] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + +A.3. Model 2: AMI with Neighborhood Access to the Home + + In this second model, let's imagine that the utility directly + accesses appliances within the HAN. Rather than expect an EMS to + respond to price signals in Demand Response, it directly commands + devices like air conditioners to change state, or throws relays on + circuits to or within the home. + + +----------+ +--+ +--+ +--+ + | Meter | |D1| |D2| |D3| + +-----+----+ ++-+ ++-+ ++-+ + | | | | + ----+-+-------+----+----+---- IEEE 802.15.4 + | + +--+---+ + | +------/------ NAN + |Router| + | +------/------ Residential Broadband + +--+---+ + | + ----+--+------+----+----+---- IEEE P1901 + | | | | + +-+-+ ++-+ ++-+ ++-+ + |EMS| |D4| |D5| |D6| + +---+ +--+ +--+ +--+ + + + Figure 8: Home Area Network + + In this case, as shown in Figure 8, the Meter and EMS act as hosts on + the HAN, and there is a router between the HAN and the NAN. + + As one might imagine, there are serious security considerations in + this model. Traffic between the NAN and the residential broadband + network should be filtered, and the issues raised in Appendix A.1.2 + take on a new level of meaning. One of the biggest threats may be a + legal or at least a public relations issue; if the utility + intentionally disables a circuit in a manner or at a time that + threatens life (the resident's kidney dialysis machine is on it, or a + respirator, for example), the matter might make the papers. + Unauthorized access could be part of juvenile pranks or other things + as well. So one really wants the appliances to only obey commands + under strict authentication/authorization controls. + + In addition to the QoS issues raised in Appendix A.2, there is the + possibility of queuing issues in the router. In such a case, the IP + datagrams should probably use the Low-Latency Data Service Class + + + + +Baker & Meyer Informational [Page 65] + +RFC 6272 Internet Protocols for the Smart Grid June 2011 + + + described in [RFC4594], and let other traffic use the Standard + Service Class or other service classes. + +A.4. Model 3: Collector Is an IP Router + + In this third model, the relationship between the NAN and the HAN is + either as in Appendix A.2 or Appendix A.3; what is different is that + the collector may be an IP router. In addition to whatever + autonomous activities it is doing, it forwards traffic as an IP + router in some cases. + + Analogous to Appendix A.3, there are serious security considerations + in this model. Traffic being forwarded should be filtered, and the + issues raised in Appendix A.1.2 take on a new level of meaning -- but + this time at the utility mainframe. Unauthorized access is likely + similar to other financially-motivated attacks that happen in the + Internet, but presumably would be coming from devices in the HAN that + have been co-opted in some way. One really wants the appliances to + only obey commands under strict authentication/authorization + controls. + + In addition to the QoS issues raised in Appendix A.2, there is the + possibility of queuing issues in the collector. In such a case, the + IP datagrams should probably use the Low-Latency Data Service Class + described in [RFC4594], and let other traffic use the Standard + Service Class or other service classes. + +Authors' Addresses + + Fred Baker + Cisco Systems + Santa Barbara, California 93117 + USA + + EMail: fred@cisco.com + + + David Meyer + Cisco Systems + Eugene, Oregon 97403 + USA + + EMail: dmm@cisco.com + + + + + + + + +Baker & Meyer Informational [Page 66] + |