| Network Working Group | F.J. Baker |
| Internet-Draft | D.M. Meyer |
| Intended status: Informational | Cisco Systems |
| Expires: September 16, 2011 | March 15, 2011 |
Internet Protocols for the Smart Grid
draft-baker-ietf-core-13
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.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 16, 2011.
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.
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 the Wikipedia [SmartGrid],
That description focuses on the implications of Smart Grid technology in the home of a consumer. In fact, data communications technologies of various kinds are used throughout the Grid, to monitor and maintain power generation, transmission, and distribution, as well as the operations and management of the Grid. One can view the Smart Grid as a collection of interconnected computer networks that connects and serves the needs of public and private electrical utilities and their customers.
At 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 which 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 Comment (RFC) series. Several RFCs have been written describing how the IPS should be implemented. These include:
At this writing, RFC 4294 is in the process of being updated, in [I-D.ietf-6man-node-req-bis].
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:
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.
While Internet architecture uses the definitions and language similar to language used by the ISO Open System Interconnect Reference (ISO-OSI) 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 | +--------------------+
The structure of the Internet reference model is shown in Figure 2.
+---------------------------------+ |Application | | +---------------------------+ | | | Application Protocol | | | +----------+----------------+ | | | Encoding | Session Control| | | +----------+----------------+ | +---------------------------------+ |Transport | | +---------------------------+ | | | Transport layer | | | +---------------------------+ | +---------------------------------+ |Network | | +---------------------------+ | | | Internet Protocol | | | +---------------------------+ | | | Lower network layers | | | +---------------------------+ | +---------------------------------+ |Media layers | | +---------------------------+ | | | Data Link Layer | | | +---------------------------+ | | | Physical Layer | | | +---------------------------+ | +---------------------------------+
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.
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 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.
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.
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.
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.
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.
While it is popular to complain about the security of the Internet, it is important to distinguish between attacks on protocols and attacks on user (e.g., phishing). Attacks on users are largely independent of protocol details, reflecting interface design issues or user education problems, and are out of scope for this document. Security problems with Internet protocols are in scope, of course, and can often be mitigated using existing security features already specified for the protocol, or by leveraging the security services offered by other IETF protocols. See the Security Assessment of the Transmission Control Protocol (TCP) [I-D.ietf-tcpm-tcp-security] and the Security Assessment of the Internet Protocol version 4 [I-D.ietf-opsec-ip-security] 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 consideration section to document the offered security threats and countermeasures. RFC 3522 [RFC3522] provides recommendations writing such a security consideration 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 it 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.
At the physical and data link layers, threats generally center on physical attacks on the network - the effects of backhoes, deterioration of physical media, and various kinds of environmental noise. Radio-based networks are subject to signal fade due to distance, interference, and environmental factors; it is widely noted that IEEE 802.15.4 networks frequently place a metal ground plate between the meter and the device that manages it. Fiber was at one time deployed because it was believed to be untrappable; 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 to restrict access to their infrastructure 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.
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):
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 still valid (e.g. active subscription and sufficient credits).
From the discussion above, establishing a secure communication channel is clearly an important concept frequently used to mitigate a range of attacks. Unfortunately, focusing only on channel security may not be enough for a given task. Threat models have evolved and even some of the communication endpoints cannot be considered fully trustworthy, i.e. even trusted peers may act maliciously.
Furthermore, many protocols are more sophisticated in their protocol interaction and involve more than two parties in the protocol exchange. Many of the application layer protocols, such as email, instant messaging, voice over IP, and presence based applications, fall into this category. With this class of protocols in addition to secure channels between two parties also security between non-neighboring communication partners need to be considered. 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.
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.
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.
Network management has proven to be a difficult problem. As such, various solutions have been proposed, implemented, and deployed. Each solution has its proponents, all of whom have solid arguments for their viewpoints. The IETF has two major network management solutions for device operation: SNMP, which is ASN.1-encoded and is primarily used for monitoring of system variables, and NetConf [RFC4741], which is XML-encoded and primarily used for device configuration.
Another aspect of network management is the initial provisioning and configuration of hosts, which is discussed in Section 3.4.2. Note that Smart Grid deployments may require identity authentication and authorization (as well as other provisioning and configuration) that may not be within the scope of either DHCP or Neighbor Discovery. While the IP Protocol Suite has limited support for secure provisioning and configuration, these problems have been solved using IP protocols in specifications such as DOCSIS 3.0 [SP-MULPIv3.0].
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.
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. Re-using 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 unique to the specific domain that protocol operates in. 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.
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], [I-D.ietf-dime-rfc3588bis]) 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 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 RFC 5216 [RFC5216], 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 PANA [RFC5193] 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 re-used for application layer protocols. More details about this architectural variant can be found in [I-D.lear-abfab-arch].
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) [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 development 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).
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][I-D.mcgrew-tls-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] [I-D.ietf-tls-rfc4347-bis]) was developed.
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 with 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]. CMS has been leveraged to supply security services in a variety of protocols, including secure email [RFC5751], key management [RFC5958] and [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 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], [I-D.ietf-oauth-v2]. 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 to shares 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 obtains an access token, a string denoting a specific scope, duration, and other access attributes, during the OAuth protocol exchange securely gain access to the protected resource with the consent of the resource owner.
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 RIR free pools are expected to be exhausted during them coming year at most. The IETF, the IANA, and the Regional Internet Registrars recommends that new deployments use IPv6, and that IPv4 infrastructures are supported via the mechanisms described in Section 3.2.1.
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 [I-D.arkko-ipv6-transition-guidelines]. The thoughts in that document are replicated here.
The simplest coexistence approach is to
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].
In those places in the network that support only IPv4 the simplest and most reliable approach is to provide virtual connectivity using tunnels or encapsulations. Early in the IPv6 deployment, this was often done using static tunnels. A more dynamic approach is documented in IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5569].
In those cases where an IPv4-only host would like to communicate with an IPv6-only host (or vice versa), 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 on 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:
As with IPv4/IPv4 Network Address Translation, translation between IPv4 and IPv6 has limited real world applicability for an application protocol which carry 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.
IPv4 [RFC0791] and the Internet Control Message Protocol [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 the Internet Control Message Protocol (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 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.
IPv4 addresses are administratively assigned, usually using automated methods, and assigned using the Dynamic Host Configuration Protocol (DHCP) [RFC2131]. On most interface types, neighboring systems identify each other's addresses using the Address Resolution Protocol (ARP) [RFC0826].
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 it will be delivered to. 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.
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 "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].
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 [RFC4919] RFC and the Compression Format for IPv6 Datagrams in 6LoWPAN Networks [I-D.ietf-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.
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 which may be advantageous in different use cases. Autoconfiguration procedures are defined in [RFC4862] and [RFC4941]. IPv6 neighbors identify each other's addresses using either Neighbor Discovery (ND) [RFC4861]. SEcure Neighbor Discovery (SEND) [RFC3971] may be used to secure these operations.
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 it will be delivered to. 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.
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.
The Open Shortest Path First (OSPF) routing protocol is one of the more widely used protocols in the Internet. OSPF is a 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] to route 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 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.
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 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.
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. Multi-protocol 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.
The Mobile Ad Hoc Working Group of the IETF developed, among other protocols, the 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 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 [I-D.ietf-manet-dymo] protocol.
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.
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 and maintained 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.
The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) [I-D.ietf-roll-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:
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.
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 it is the responsibility of the receivers (rather than the network) to find the (S,G) channel they are interested in receiving. This implies that SSM requires some form of directory service so that receivers can find the (S,G) channels.
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:
Numerous other adaptation specifications exist, including ATM, Frame Relay, X.25, other standardized and proprietary LAN technologies, and others.
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 built for specific purposes. Other transport protocols can be built when required.
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 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.
TCP [RFC0793] is the predominant transport protocol in use 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 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.
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.
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.
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.
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].
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].
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.
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].
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.
The Simple Network Management Protocol, originally specified in the late 1980's and having passed through several revisions, is specified in several documents:
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.
The NETCONF Configuration Protocol is specified in one basic document, with supporting documents for carrying it over the IPS. These documents include:
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.
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.
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 [I-D.cheshire-dnsext-multicastdns] and the automatic location of network services via DHCP [dhcp], the DNS Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part of Apple's Bonjour technology) and the Service Location Protocol (SLP) [RFC2608].
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:
The Constrained Application Protocol (CoAP) [I-D.ietf-core-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 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) [I-D.cheshire-dnsext-dns-sd].
Resource discovery in CoAP is accomplished through the use of well-known resources which 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.
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.
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, 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 SDP: Session Description Protocol [RFC4566] is intended for those purposes. Within the SDP, which is transported by SIP, codecs are offered and accepted (or not), the port number and IP address is decided for where each endpoint wants to receive their Real-time Transport Protocol (RTP) [RFC3550] packets. The introduction of Network Address Translation (NAT) technology into the profile, whether IPv4/IPv4, IPv4/IPv 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].
The Extensible Messaging and Presence Protocol (XMPP) [RFC3920] 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 [RFC3921] 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], and the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) [RFC5122], and the presentation of Notifications [RFC5437].
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 [I-D.daboo-et-al-icalendar-in-xml] Several protocols exist to carry calendar events, including iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the Message-Based Interoperability Protocol (iMIP) [RFC6047] , and open source work on the Atom Publishing Protocol [RFC5023].
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 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 |
| |
\ /
\ /
------
A specific example is shown in a traceroute from a home to a nearby school. Internet connectivity in Figure 4 passes through
<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 * * *
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.
<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 ...
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, 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.
Key documents describing firewall technology and the issues it poses include:
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:
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]. .
This memo asks the IANA for no new parameters.
Note to RFC Editor: This section will have served its purpose if it correctly tells IANA that no new assignments or registries are required, or if those assignments or registries are created during the RFC publication process. From the author"s perspective, it may therefore be removed upon publication as an RFC at the RFC Editor's discretion.
Security is addressed in some detail in Section 2.2 and Section 3.1.
Review comments were made by Andrew Yourtchenko, Ashok Narayanan, Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, Don Sturek, Francis Cleveland, Hemant Singh, James Polk, John Meylor, Joseph Salowey, Julien Abeille, Kerry Lynn, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman, Ralph Droms, Russ White, Sheila Frankel, Tom Herbst, and Toerless Eckert. Dave McGrew, Vint Cerf, and Ralph Droms suggested text. In addition, numerous review comments were made by the IESG, which have been picked up as well.
| [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. |
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 an front-end application V +----+-----+ gateway for utility --- \ A \ | / | \ | / |"AMI" +--+-+-+--+ | | AMI | | | Headend | V +---------+ ---
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:
In implementation, these models are idealized; reality may include some aspects of each model in specified cases.
The examples include:
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 [1822]. 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 related to the IPS, and as a result require little or no change to continue to operate 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.
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 +----+-----+
\ / ---
-------
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.
Figure 7 shows two simple networks, one of which 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 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.
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 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.
In any network, we have a variety of threats and a variety of possible mitigations. These include, at minimum:
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 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.
With the background given in Appendix 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.
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
| | |
++-+ ++-+ ++-+
|D4| |D5| |D6|
+--+ +--+ +--+
In this case, as shown in Figure 8, the Meter, and EMS 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 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 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 described in [RFC4594], and let other traffic use the Standard Service Class or other service classes.
In this third model, the relationship between the NAN and the HAN is either as in Appendix Appendix A.2 or Appendix 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.
As and analogous to Appendix Appendix A.3, there are serious security considerations in this model. Traffic being forwarded should be filtered, and the issues raised in Appendix 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 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.