Internet Protocols for the Smart Grid
draft-baker-ietf-core-09

Abstract

This note identifies the key 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 Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This Internet-Draft will expire on April 28, 2011.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1.  Introduction
2.  The Internet Protocol Suite
    2.1.  Internet Protocol Layers
        2.1.1.  Application
        2.1.2.  Transport
        2.1.3.  Network
            2.1.3.1.  Internet Protocol
            2.1.3.2.  Lower layer networks
        2.1.4.  Media layers: Physical and Link
    2.2.  Security issues
        2.2.1.  Physical security
        2.2.2.  Session Authentication
        2.2.3.  Confidentiality
    2.3.  Network Infrastructure
        2.3.1.  Domain Name System (DNS)
        2.3.2.  Network Management
3.  Specific protocols
    3.1.  Security solutions
        3.1.1.  Session identification, authentication, authorization, and accounting
        3.1.2.  IP Security Architecture (IPsec)
        3.1.3.  Transport Layer Security (TLS)
        3.1.4.  Secure/Multipurpose Internet Mail Extensions (S/MIME)
    3.2.  Network Layer
        3.2.1.  IPv4/IPv6 Coexistence Advice
            3.2.1.1.  Dual Stack Coexistence
            3.2.1.2.  Tunneling Mechanism
            3.2.1.3.  Translation between IPv4 and IPv6 Networks
        3.2.2.  Internet Protocol Version 4
            3.2.2.1.  IPv4 Address Allocation and Assignment
            3.2.2.2.  IPv4 Unicast Routing
            3.2.2.3.  IPv4 Multicast Forwarding and Routing
        3.2.3.  Internet Protocol Version 6
            3.2.3.1.  IPv6 Address Allocation and Assignment
            3.2.3.2.  IPv6 Routing
        3.2.4.  Routing for IPv4 and IPv6
            3.2.4.1.  Routing Information Protocol
            3.2.4.2.  Open Shortest Path First
            3.2.4.3.  ISO Intermediate System to Intermediate System
            3.2.4.4.  Border Gateway Protocol
            3.2.4.5.  Dynamic MANET On-demand (DYMO) Routing
            3.2.4.6.  Optimized Link State Routing Protocol
            3.2.4.7.  Routing for Low power and Lossy Networks
        3.2.5.  IPv6 Multicast Forwarding and Routing
            3.2.5.1.  Protocol-Independent Multicast Routing
        3.2.6.  Adaptation to lower layer networks and link layer protocols
    3.3.  Transport Layer
        3.3.1.  User Datagram Protocol (UDP)
        3.3.2.  Transmission Control Protocol (TCP)
        3.3.3.  Stream Control Transmission Protocol (SCTP)
        3.3.4.  Datagram Congestion Control Protocol (DCCP)
    3.4.  Infrastructure
        3.4.1.  Domain Name System
        3.4.2.  Dynamic Host Configuration
        3.4.3.  Network Time
    3.5.  Network Management
        3.5.1.  Simple Network Management Protocol (SNMP)
        3.5.2.  Network Configuration (NETCONF) Protocol
    3.6.  Service and Resource Discovery
        3.6.1.  Service Discovery
        3.6.2.  Resource Discovery
    3.7.  Other Applications
        3.7.1.  Session Initiation Protocol
        3.7.2.  Calendaring
4.  A simplified view of the business architecture
5.  IANA Considerations
6.  Security Considerations
7.  Acknowledgements
8.  References
    8.1.  Normative References
    8.2.  Informative References
Appendix A.  Example: Advanced Metering Infrastructure
    A.1.  How to structure a network
        A.1.1.  HAN Routing
        A.1.2.  HAN Security
    A.2.  Model 1: AMI with separated domains
    A.3.  Model 2: AMI with neighborhood access to the home
    A.4.  Model 3: Collector is an IP router
§  Authors' Addresses

1.  Introduction

This document provides Smart Grid designers with advice on how to best "profile" the Internet Protocol Suite (IPS) for use on with Smart Grids. It provides an overview of the IPS and the key protocols that are critical in integrating Smart Grid devices into an IP-based infrastructure.

The IPS provides options for several key architectural components. For example, the IPS provides several choices for the traditional transport function between two systems: the Transmission Control Protocol (TCP) [RFC0793] (Postel, J., “Transmission Control Protocol,” September 1981.), the Stream Control Transmission Protocol (SCTP) [RFC4960] (Stewart, R., “Stream Control Transmission Protocol,” September 2007.), and the Datagram Congestion Control Protocol (DCCP) [RFC4340] (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.). Another option is to select an encapsulation such as the User Datagram Protocol (UDP) [RFC0768] (Postel, J., “User Datagram Protocol,” August 1980.) 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:

• Requirements for Internet Hosts - Communication Layers (Braden, R., “Requirements for Internet Hosts - Communication Layers,” October 1989.) [RFC1122],
• Requirements for Internet Hosts - Application and Support (Braden, R., “Requirements for Internet Hosts - Application and Support,” October 1989.) [RFC1123],
• Requirements for IP Version 4 Routers (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) [RFC1812], and
• IPv6 Node Requirements (Loughney, J., “IPv6 Node Requirements,” April 2006.) [RFC4294],

At this writing, RFC 4294 is in the process of being updated, in [I‑D.ietf‑6man‑node‑req‑bis] (Jankiewicz, E., Loughney, J., and T. Narten, “IPv6 Node Requirements RFC 4294-bis,” July 2010.).

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:

• Section 2 (The Internet Protocol Suite) describes the Internet Architecture and its protocol suite.
• Section 3 (Specific protocols) outlines the set of protocols that will be useful in Smart Grid deployment.
• Finally, Section 4 (A simplified view of the business architecture) provides an overview of the business architecture embodied in the design and deployment of the IPS.

2.  The Internet Protocol Suite

Before enumerating the list of Internet protocols relevant to Smart Grid, we discuss the layered architecture of the IPS, the functions of the various layers, and their associated protocols.

2.1.  Internet Protocol Layers

While Internet architecture uses the definitions and language similar to language used by the ISO Open System Interconnect Reference (ISO-OSI) Model (Figure 1 (The ISO OSI Reference Model)), 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 (The Internet Reference Model).

+---------------------------------+
|Application                      |
|   +---------------------------+ |
|   | Application Protocol      | |
|   +----------+----------------+ |
|   | Encoding | Session Control| |
|   +----------+----------------+ |
+---------------------------------+
|Transport                        |
|   +---------------------------+ |
|   | Transport layer           | |
|   +---------------------------+ |
+---------------------------------+
|Network                          |
|   +---------------------------+ |
|   | Internet Protocol         | |
|   +---------------------------+ |
|   | Lower network layers      | |
|   +---------------------------+ |
+---------------------------------+
|Media layers                     |
|   +---------------------------+ |
|   | Data Link Layer           | |
|   +---------------------------+ |
|   | Physical Layer            | |
|   +---------------------------+ |
+---------------------------------+

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) [RFC1157] (Case, J., Fedor, M., Schoffstall, M., and J. Davin, “Simple Network Management Protocol (SNMP),” May 1990.) 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 (The Internet Reference Model) these functions are not necessarily cleanly layered: the fact that an application protocol encodes its data in some way and that it manages sessions in some way doesn't imply a hierarchy between those processes. Rather, the application views encoding, session management, and a variety of other services as a tool set that it uses while doing its work.

2.1.2.  Transport

The term "transport" is perhaps among the most confusing concepts in the communication architecture, to 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] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) (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 (Postel, J., “User Datagram Protocol,” August 1980.) [RFC0768], TCP (Postel, J., “Transmission Control Protocol,” September 1981.) [RFC0793], DCCP (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.) [RFC4340], SCTP (Stewart, R., “Stream Control Transmission Protocol,” September 2007.) [RFC4960], and NORM (Adamson, B., Bormann, C., Handley, M., and J. Macker, “NACK-Oriented Reliable Multicast (NORM) Transport Protocol,” November 2009.) [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 includes 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 rate to avoid loss, 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] (Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” January 2001.) or Asynchronous Transfer Mode (ATM), a path is set up once, and data is delivered through it. In connectionless networks such as Ethernet and IP, data is delivered as datagrams. Each datagram contains both the source and destination network layer addresses, and the network is responsible for delivering it. In the Internet Protocol Suite, the Internet Protocol is the network that runs end to end. It may be encapsulated over other LAN and WAN technologies, including both IP networks and networks of other types.

2.1.3.1.  Internet Protocol

IPv4 and IPv6, each of which is called the Internet Protocol, are connectionless ("datagram") architectures. They are designed as common elements that interconnect network elements across a network of lower layer networks. In addition to the basic service of identifying a datagram's source and destination, they offer services to fragment and reassemble datagrams when necessary, assist in diagnosis of network failures, and carry additional information necessary in special cases.

The Internet layer provides a uniform network abstraction network that hides the differences between different 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 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] (Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE),” March 2000.). In addition, IP is also frequently carried in circuit networks such as MPLS [RFC4364] (Rosen, E. and Y. Rekhter, “BGP/MPLS IP Virtual Private Networks (VPNs),” February 2006.), GMPLS, and ATM. Finally, IP is also carried over local wireless (IEEE 802.11, 802.15.4, or 802.16) networks 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 it is popular to complain about the security of the Internet, solutions to many Internet security problems already exist but have either not been widely deployed, may impact critical performance criteria, or require security measures outside the IPS. Internet security solutions attempt to mitigate a set of known threats within the IPS domain at a specified cost; addressing security issues requires first a threat analysis and assessment and a set of mitigations appropriate to the threats. Since we have threats at every layer, we should expect to find mitigations at every layer.

2.2.1.  Physical security

At the physical and data link layers, threats generally center on physical attacks on the network - the effects of backhoes, deterioration of physical media, and various kinds of environmental noise. Radio-based networks are subject to signal fade due to distance, interference, and environmental factors; it is widely noted that IEEE 802.15.4 networks frequently place a metal ground plate between the meter and the device that manages it. Fiber was at one time deployed because it was believed to be untappable; we have since learned to tap it by bending the fiber and collecting incidental light, and we have learned about backhoes. As a result, some installations encase fiber optic cable in a pressurized sheath, both to quickly identify the location of a cut and to make it more difficult to tap.

While there are protocol behaviors that can detect certain classes of physical faults, such as keep-alive exchanges, physical security is generally not considered to be a protocol problem.

2.2.2.  Session Authentication

At the transport and application layers and in lower layer networks where dynamic connectivity such as ATM Switched Virtual Circuits (SVCs) or "dial" connectivity are in use, there tend to be several different classes of authentication/authorization requirements. The basic requirements that must be satisfied are:

1. Verify that peers are appropriate partners; this generally means knowing "who" they are and that they have a "need to know" or are trusted sources.
2. Verify that information that appears to be from a trusted peer is in fact from that peer.
3. Validate the content of the data exchanged; it must conform to the rules of the exchange.
4. Defend the channel against denial of service attacks.
5. Ensure the integrity of the information transported to defend against modification attacks.

In other words, both the communications channel itself and message exchanges (both by knowing the source of the information and to have proof of its validity) must be secured. Three examples suffice to illustrate the challenges.

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. Experience has shown that by including information in the transport header or a related protocol like the IPsec (Section 3.1.2 (IP Security Architecture (IPsec))) or TLS (Section 3.1.3 (Transport Layer Security (TLS))), 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 communication with a router or a service. For example, an unauthorized party might try to join the routing system. To protect against such attacks, an Internet Service Provider (ISP) should not accept information from new peers without verifying that the peer is who it claims to be and that the peer is authorized to carry on the exchange of information.

More generally, in order to secure a communications channel, it must be possible to verify that messages putatively received from a peer were in fact received from that peer. Only once messages are verified as coming a trusted peer should a host or router engage in communications with the peer.

Unfortunately, even trusted peers forward incorrect or malicious data. As a result, securing the channel is not sufficient; information exchanged through the channel must also be secured. In electronic mail and other database exchanges, it may be necessary to be able to verify the identity of the sender and the correctness of the content long after the information exchange has occurred - for example, if a contract is exchanged that is secured by digital signatures, one will wish to be able to verify those signatures at least throughout the lifetime of the contract, and probably a long time after that.

2.2.3.  Confidentiality

In addition to securing the communications channel and messaging, there frequently a requirement for confidentiality. Confidentiality arises at several layers, sometimes simultaneously. For example, providers of credit card transaction services want application layer privacy, which can be supplied by encrypting application data or by an encrypted transport layer. If an ISP (or other entity) wants to hide its network structure, it can to encrypt the network layer header.

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 (Domain Name System).

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 is a polled architecture, and NetConf [RFC4741] (Enns, R., “NETCONF Configuration Protocol,” December 2006.), 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 (Dynamic Host Configuration). 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 does not have specific solutions for secure provisioning and configuration, these problems have been solved using IP protocols in specifications such as DOCSIS 3.0 (CableLabs, “DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.0-I10-090529,” May 2009.) [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 privacy, Authentication, Authorization, and Accounting (AAA), transport and network solution dimensions. The following sections provide guidance for such analyzes.

3.1.  Security solutions

As noted, a key consideration in security solutions is a good threat analysis coupled with appropriate mitigation strategies at each layer. The following sections outline the security features of the IPS.

3.1.1.  Session identification, authentication, authorization, and accounting

The IPS provides approaches to Authentication, Authorization, and Accounting (AAA) issues. Since these different approaches have different attack surfaces and protection domains, they require some thought in application. The two major approaches to AAA taken by the IPS are the IP Security Architecture (Section 3.1.2 (IP Security Architecture (IPsec))), which protects IP datagrams, and Transport Layer Security (Section 3.1.3 (Transport Layer Security (TLS))), which protects the information which the transport layer delivers.

3.1.2.  IP Security Architecture (IPsec)

The Security Architecture for the Internet Protocol (IPsec) (Kent, S. and K. Seo, “Security Architecture for the Internet Protocol,” December 2005.) [RFC4301] is a set of control and data protocols that are implemented between IPv4 and the chosen transport layer, or in IPv6's security extension header. It allows transport layer sessions to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. As is typical with IETF specifications, the architecture is spelled out in a number of documents which specify the specific components: the IP Authentication Header (AH) (Kent, S., “IP Authentication Header,” December 2005.) [RFC4302] Encapsulating Security Payload (ESP) (Kent, S., “IP Encapsulating Security Payload (ESP),” December 2005.) [RFC4303], Internet Key Exchange (IKEv2) (Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, “Internet Key Exchange Protocol Version 2 (IKEv2),” September 2010.) [RFC5996], Cryptographic Algorithms (Schiller, J., “Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2),” December 2005.) [RFC4307], Cryptographic Algorithm Implementation Requirements for ESP and AH (Manral, V., “Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH),” April 2007.) [RFC4835], and the use of Advanced Encryption Standard (AES) (Housley, R., “Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP),” December 2005.) [RFC4309].

IPsec provides two modes: Transport mode and tunnel mode. In transport mode, IPsec ESP encrypts the transport layer and the application data. In tunnel mode, the source IP datagram is encrypted and encapsulated in a second IP header addressed to the intended decryptor. As might be expected, tunnel mode is frequently used for virtual private networks which need to securely transmit data across networks with unknown (or no) other security properties. In both cases, authentication, authorization, and confidentiality extend from system to system, and apply to all applications that the two systems use.

Note that IPsec can provide non-repudiation when an asymmetric authentication algorithm is used with the AH header and both sender and receiver keys are used in the authentication calculation. However, the default authentication algorithm is keyed MD5, which like all symmetric algorithms cannot provide non-repudiation by itself (since the sender's key is not used in the computation). So while IPsec provides a means of authenticating network level objects (packets), these objects are are ephemeral and not directly correlated with a particular application. As a result non-repudiation is not generally applicable to network level objects such as packets.

3.1.3.  Transport Layer Security (TLS)

Transport Layer Security (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] and Datagram Transport Layer Security (Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security,” April 2006.) [RFC4347][I‑D.ietf‑tls‑rfc4347‑bis] (Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security version 1.2,” July 2010.) are mechanisms that travel within the transport layer protocol data unit, meaning that they readily traverse network address translators and secure the information exchanges without securing the datagrams exchanged or the transport layer itself. Each allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. Authentication, authorization, and confidentiality exist for a session between specific applications.

In order to communicate securely, an TLS client and TLS server must agree on the cryptographic algorithms and keys that they will use on the secured connection. In particular, they must agree on these items:

• Key Establishment Algorithm
• Peer Authentication Algorithm
• Bulk Data Encryption Algorithm and key size
• Digest Algorithm

Since each categories has multiple options, the number of possible combinations is large. As a result, TLS does not allow all possible combinations of choices; rather it only allows certain well-defined combinations known as Cipher Suites. [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.) outlines the use of different TLS Cipher Suites for use in the Smart Grid.

When used in conjunction with IEEE 802.1X (Institute of Electrical and Electronics Engineers, “IEEE Standard for Local and Metropolitan Area Networks - Port based Network Access Control,” February 2010.) [IEEE802.1X], both EAP-TLS (Simon, D., Aboba, B., and R. Hurst, “The EAP-TLS Authentication Protocol,” March 2008.) [RFC5216] and the Protocol for Carrying Authentication for Network Access (PANA) (Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and A. Yegin, “Protocol for Carrying Authentication for Network Access (PANA) Framework,” May 2008.) [RFC5193] are widely considered to offer excellent access security to a wired or wireless IEEE 802 LAN (IEEE 802.1X in conjunction with EAP-TLS is the baseline for Zigbee SEP 2.0).

3.1.4.  Secure/Multipurpose Internet Mail Extensions (S/MIME)

The S/MIME (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) [RFC2045] [RFC2046] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” November 1996.) [RFC2047] (Moore, K., “MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text,” November 1996.) [RFC4289] (Freed, N. and J. Klensin, “Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures,” December 2005.) [RFC2049] (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples,” November 1996.) [RFC5750] (Ramsdell, B. and S. Turner, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling,” January 2010.) [RFC5751] (Ramsdell, B. and S. Turner, “Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification,” January 2010.) [RFC4262] (Santesson, S., “X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities,” December 2005.) specification was originally designed as an extension to SMTP Mail to provide evidence that the putative sender of an email message in fact sent it, and that the content received was in fact the content that was sent. As its name suggests, by extension this is a way of securing any object that can be exchanged, by any means, and has become one of the most common ways to secure an object.

Related work includes the use of digital signatures on XML-encoded files, which has been jointly standardized by W3C and the IETF [RFC3275] (Eastlake, D., Reagle, J., and D. Solo, “(Extensible Markup Language) XML-Signature Syntax and Processing,” March 2002.).

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 since IPv4 free pool (the pool of available, unallocated IPv4 addresses) is almost exhausted, the IETF recommends that new deployments use IPv6 and that IPv4 infrastructures are supported via the mechanisms described in Section 3.2.1 (IPv4/IPv6 Coexistence Advice).

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 (Arkko, J. and F. Baker, “Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment,” August 2010.) [I‑D.arkko‑ipv6‑transition‑guidelines]. The thoughts in that document are replicated here.

3.2.1.1.  Dual Stack Coexistence

The simplest coexistence approach is to

• provide a network that routes both IPv4 and IPv6,
• ensure that servers similarly support both protocols, and
• require that all new systems 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 (Nordmark, E. and R. Gilligan, “Basic Transition Mechanisms for IPv6 Hosts and Routers,” October 2005.) [RFC4213].

3.2.1.2.  Tunneling Mechanism

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) (Despres, R., “IPv6 Rapid Deployment on IPv4 Infrastructures (6rd),” January 2010.) [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), 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:

• Framework for IPv4/IPv6 Translation (Baker, F., Li, X., Bao, C., and K. Yin, “Framework for IPv4/IPv6 Translation,” August 2010.) [I‑D.ietf‑behave‑v6v4‑framework]
• IPv6 Addressing of IPv4/IPv6 Translators (Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, “IPv6 Addressing of IPv4/IPv6 Translators,” August 2010.) [I‑D.ietf‑behave‑address‑format]
• DNS extensions (Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, “DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers,” October 2010.) [I‑D.ietf‑behave‑dns64]
• IP/ICMP Translation Algorithm (Li, X., Bao, C., and F. Baker, “IP/ICMP Translation Algorithm,” September 2010.) [I‑D.ietf‑behave‑v6v4‑xlate]
• Translation from IPv6 Clients to IPv4 Servers (Bagnulo, M., Matthews, P., and I. Beijnum, “Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers,” July 2010.) [I‑D.ietf‑behave‑v6v4‑xlate‑stateful]

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 does however have 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 networks site networks are IPv6 only while some transits 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 (Postel, J., “Internet Protocol,” September 1981.) [RFC0791] and the Internet Control Message Protocol (Postel, J., “Internet Control Message Protocol,” September 1981.) [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] (Postel, J., “Internet Control Message Protocol,” September 1981.), 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) (Callon, R., “Use of OSI IS-IS for routing in TCP/IP and dual environments,” December 1990.) [RFC1195] and OSPF Version 2 (Moy, J., “OSPF Version 2,” April 1998.) [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 (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.) [RFC2474][RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.), 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 (Babiarz, J., Chan, K., and F. Baker, “Configuration Guidelines for DiffServ Service Classes,” August 2006.) [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, and assigned using the Dynamic Host Configuration Protocol (DHCP) (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [RFC2131]. On most interface types, neighboring equipment identify each other's addresses using Address Resolution Protocol (ARP) (Plummer, D., “Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware,” November 1982.) [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 it will be delivered to. This 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 Version 2 (Malkin, G., “RIP Version 2,” November 1998.) [RFC2453], OSI IS-IS for IPv4 (Callon, R., “Use of OSI IS-IS for routing in TCP/IP and dual environments,” December 1990.) [RFC1195], OSPF Version 2 (Moy, J., “OSPF Version 2,” April 1998.) [RFC2328], and BGP-4 (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) [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] (Deering, S., “Host extensions for IP multicasting,” August 1989.). This uses the Internet Group Management Protocol (Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, “Internet Group Management Protocol, Version 3,” October 2002.) [RFC3376][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,” August 2006.) to enable applications to join multicast groups, and for most applications uses Source-Specific Multicast (Holbrook, H. and B. Cain, “Source-Specific Multicast for IP,” August 2006.) [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 (Mankin, A., Romanov, A., Bradner, S., and V. Paxson, “IETF Criteria for Evaluating Reliable Multicast Transport and Application Protocols,” June 1998.) [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 (Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, “The Use of Forward Error Correction (FEC) in Reliable Multicast,” December 2002.) [RFC3453], the Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol (Adamson, B., Bormann, C., Handley, M., and J. Macker, “NACK-Oriented Reliable Multicast (NORM) Transport Protocol,” November 2009.) [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP) (Pullen, M., Zhao, F., and D. Cohen, “Selectively Reliable Multicast Protocol (SRMP),” February 2006.) [RFC4410]. These are considered experimental.

3.2.3.  Internet Protocol Version 6

IPv6 (Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification,” December 1998.) [RFC2460], with the Internet Control Message Protocol "v6" (Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification,” March 2006.) [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 (Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” December 1998.) [RFC2474][RFC2475] (Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, “An Architecture for Differentiated Services,” December 1998.), 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 (Kushalnagar, N., Montenegro, G., and C. Schumacher, “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals,” August 2007.) [RFC4919] RFC and the Compression Format for IPv6 Datagrams in 6LoWPAN Networks (Hui, J. and P. Thubert, “Compression Format for IPv6 Datagrams in 6LoWPAN Networks,” September 2010.) [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.

3.2.3.1.  IPv6 Address Allocation and Assignment

An IPv6 Address (Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture,” February 2006.) [RFC4291] may be administratively assigned using DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [RFC3315] in a manner similar to the way IPv4 addresses are. In addition, IPv6 addresses may also be autoconfigured. Autoconfiguation enables various different models of network management which may be advantageous in various use cases. Autoconfiguration procedures are defined in [RFC4862] (Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” September 2007.) and [RFC4941] (Narten, T., Draves, R., and S. Krishnan, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6,” September 2007.). IPv6 neighbors identify each other's addresses using either Neighbor Discovery (ND) (Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6),” September 2007.) [RFC4861] or SEcure Neighbor Discovery (SEND) (Arkko, J., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND),” March 2005.) [RFC3971].

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 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 (Malkin, G. and R. Minnear, “RIPng for IPv6,” January 1997.) [RFC2080], IS-IS for IPv6 (Hopps, C., “Routing IPv6 with IS-IS,” October 2008.) [RFC5308], OSPF for IPv6 (Coltun, R., Ferguson, D., Moy, J., and A. Lindem, “OSPF for IPv6,” July 2008.) [RFC5340], and BGP-4 for IPv6 (Marques, P. and F. Dupont, “Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing,” March 1999.) [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 (Hedrick, C., “Routing Information Protocol,” June 1988.) [RFC1058]. People that use it today tend to deploy RIPng for IPv6 (Malkin, G. and R. Minnear, “RIPng for IPv6,” January 1997.) [RFC2080] and RIP Version 2 (Malkin, G., “RIP Version 2,” November 1998.) [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] (Hedrick, C., “Routing Information Protocol,” June 1988.) 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 a based on Dijkstra's well known shortest path first (SPF) algorithm. It is implemented as OSPF Version 2 (Moy, J., “OSPF Version 2,” April 1998.) [RFC2328] for IPv4, OSPF for IPv6 (Coltun, R., Ferguson, D., Moy, J., and A. Lindem, “OSPF for IPv6,” July 2008.) [RFC5340] for IPv6, and the Support of Address Families in OSPFv3 (Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, “Support of Address Families in OSPFv3,” April 2010.) [RFC5838] to enable [RFC5340] (Coltun, R., Ferguson, D., Moy, J., and A. Lindem, “OSPF for IPv6,” July 2008.) 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.

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 CLNS, and extended for routing in TCP/IP and dual environments (Callon, R., “Use of OSI IS-IS for routing in TCP/IP and dual environments,” December 1990.) [RFC1195], and more recently for routing of IPv6 (Hopps, C., “Routing IPv6 with IS-IS,” October 2008.) [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) (Rekhter, Y., Li, T., and S. Hares, “A Border Gateway Protocol 4 (BGP-4),” January 2006.) [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 (Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4,” January 2007.) [RFC4760] to BGP allow BGP to carry IPv6 Inter-Domain Routing (Marques, P. and F. Dupont, “Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing,” March 1999.) [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, the Ad hoc On-Demand Distance Vector (AODV) Routing (Perkins, C., Belding-Royer, E., and S. Das, “Ad hoc On-Demand Distance Vector (AODV) Routing,” July 2003.) [RFC3561]. This protocol captured the minds of some in the embedded devices industry, but experiences 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 updatedDynamic MANET On-demand (DYMO) Routing (Chakeres, I. and C. Perkins, “Dynamic MANET On-demand (DYMO) Routing,” July 2010.) [I‑D.ietf‑manet‑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) (Clausen, T. and P. Jacquet, “Optimized Link State Routing Protocol (OLSR),” October 2003.) [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 device 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.

3.2.4.7.  Routing for Low power and Lossy Networks

The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) [I‑D.ietf‑roll‑rpl] (Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Networks, D., Struik, R., and J. Vasseur, “RPL: IPv6 Routing Protocol for Low power and Lossy Networks,” October 2010.) is a reactive routing protocol designed for use in resource constrained networks. Requirements for resource constrained networks are defined in [RFC5548] (Dohler, M., Watteyne, T., Winter, T., and D. Barthel, “Routing Requirements for Urban Low-Power and Lossy Networks,” May 2009.), [RFC5673] (Pister, K., Thubert, P., Dwars, S., and T. Phinney, “Industrial Routing Requirements in Low-Power and Lossy Networks,” October 2009.), [RFC5826] (Brandt, A., Buron, J., and G. Porcu, “Home Automation Routing Requirements in Low-Power and Lossy Networks,” April 2010.), and [RFC5867] (Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, “Building Automation Routing Requirements in Low-Power and Lossy Networks,” June 2010.).

Briefly, a constrained network is comprised of nodes that:

• Are built with limited processing power and memory, and sometimes energy when operating on batteries.
• Are interconnected through a low-data-rate network interface and potentially vulnerable to communication instability and low packet delivery rates.
• 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).

3.2.5.  IPv6 Multicast Forwarding and Routing

IPv6 specifies both unicast and multicast datagram exchange. This uses the Multicast Listener Discovery Protocol (MLDv2) (Deering, S., Fenner, W., and B. Haberman, “Multicast Listener Discovery (MLD) for IPv6,” October 1999.) [RFC2710] [RFC3590] (Haberman, B., “Source Address Selection for the Multicast Listener Discovery (MLD) Protocol,” September 2003.) [RFC3810] (Vida, R. and L. Costa, “Multicast Listener Discovery Version 2 (MLDv2) for IPv6,” June 2004.) [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,” August 2006.) to enable applications to join multicast groups, and for most applications uses Source-Specific Multicast (Holbrook, H. and B. Cain, “Source-Specific Multicast for IP,” August 2006.) [RFC4607] for routing and delivery of multicast messages.

The mechanisms experimentally developed for reliable multicast in IPv4, discussed in Section 3.2.2.3 (IPv4 Multicast Forwarding and Routing), 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.

A the highest level, 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) (Adams, A., Nicholas, J., and W. Siadak, “Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised),” January 2005.) [RFC3973] and Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) (Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, “Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised),” August 2006.) [RFC4601] were designed for the ASM model.

Many modern multicast deployments use Source-Specific Multicast (PIM-SSM) [RFC3569] (Bhattacharyya, S., “An Overview of Source-Specific Multicast (SSM),” July 2003.)[RFC4608] (Meyer, D., Rockell, R., and G. Shepherd, “Source-Specific Protocol Independent Multicast in 232/8,” August 2006.). In the SSM model, a host expresses interest in a "channel", which is comprised of a source (S) and a group (G). Distribution tress are rooted 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.

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] (Hornig, C., “Standard for the transmission of IP datagrams over Ethernet networks,” April 1984.). IPv6 does the same using [RFC2464] (Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks,” December 1998.).

PPP:

The IETF has defined a serial line protocol, the Point-to-Point Protocol (PPP) (Simpson, W., “The Point-to-Point Protocol (PPP),” July 1994.) [RFC1661], that uses HDLC (bit-synchronous or byte synchronous) framing. The IPv4 adaptation specification is [RFC1332] (McGregor, G., “The PPP Internet Protocol Control Protocol (IPCP),” May 1992.), and the IPv6 adaptation specification is [RFC5072] (S.Varada, Haskins, D., and E. Allen, “IP Version 6 over PPP,” September 2007.). Current use of this protocol is in traditional serial lines, authentication exchanges in DSL networks using PPP Over Ethernet (PPPoE) (Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, “A Method for Transmitting PPP Over Ethernet (PPPoE),” February 1999.) [RFC2516], and in the Digital Signaling Hierarchy (generally referred to as Packet-on-SONET/SDH) using PPP over SONET/SDH (Malis, A. and W. Simpson, “PPP over SONET/SDH,” June 1999.) [RFC2615].

IEEE 802.15.4:

The adaptation specification for IPv6 transmission over IEEE 802.15.4 Networks is [RFC4944] (Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks,” September 2007.).

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 built for specific purposes. Other transport protocols can be built when required.

3.3.1.  User Datagram Protocol (UDP)

The User Datagram Protocol (Postel, J., “User Datagram Protocol,” August 1980.) [RFC0768] and the Lightweight User Datagram Protocol (Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, “The Lightweight User Datagram Protocol (UDP-Lite),” July 2004.) [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 all that well. 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 (Eggert, L. and G. Fairhurst, “Unicast UDP Usage Guidelines for Application Designers,” November 2008.) [RFC5405].

Datagram Transport Layer Security (Phelan, T., “Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP),” May 2008.) [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 (Postel, J., “Transmission Control Protocol,” September 1981.) [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 (Allman, M., Paxson, V., and E. Blanton, “TCP Congestion Control,” September 2009.) [RFC5681] and Explicit Congestion Notification (Ramakrishnan, K., Floyd, S., and D. Black, “The Addition of Explicit Congestion Notification (ECN) to IP,” September 2001.) [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, we generally use the ISO Transport Service on TCP (Rose, M. and D. Cass, “ISO transport services on top of the TCP: Version 3,” May 1987.) [RFC1006][RFC2126] (Pouffary, Y. and A. Young, “ISO Transport Service on top of TCP (ITOT),” March 1997.) in the application.

Transport Layer Security (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2,” August 2008.) [RFC5246] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, TCP can run over IPsec. Additionally, [RFC4987] (Eddy, W., “TCP SYN Flooding Attacks and Common Mitigations,” August 2007.) 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 End to End research group has published a Roadmap for TCP Specification Documents (Duke, M., Braden, R., Eddy, W., and E. Blanton, “A Roadmap for Transmission Control Protocol (TCP) Specification Documents,” September 2006.) [RFC4614] to capture this history, to guide TCP implementors, and provide context for TCP researchers.

3.3.3.  Stream Control Transmission Protocol (SCTP)

SCTP (Stewart, R., “Stream Control Transmission Protocol,” September 2007.) [RFC4960] is a more recent reliable transport protocol that can be imagined as a TCP-like context containing multiple separate and independent message streams (as opposed to 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 as opposed to TCP's byte stream interface, it may also be more appropriate for the ISO Transport Service than RFC 1006/2126.

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 (Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, “Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration,” September 2007.) [RFC5061], enabling peers to change addresses during the session and yet retain connectivity. Transport Layer Security (Jungmaier, A., Rescorla, E., and M. Tuexen, “Transport Layer Security over Stream Control Transmission Protocol,” December 2002.) [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 (Kohler, E., Handley, M., and S. Floyd, “Datagram Congestion Control Protocol (DCCP),” March 2006.) [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 (Phelan, T., “Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP),” May 2008.) [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) (Mockapetris, P., “Domain names - concepts and facilities,” November 1987.) [RFC1034][RFC1035] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.). 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 all a registry to sign the records it contains and as a result demonstrate their authenticity, are defined by the DNS Security Extensions [RFC4033] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements,” March 2005.)[RFC4034] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Resource Records for the DNS Security Extensions,” March 2005.)[RFC4035] (Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “Protocol Modifications for the DNS Security Extensions,” March 2005.).

Devices can also optionally update their own DNS record. For example, a sensor that is using Stateless Address Autoconfiguration (Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration,” September 2007.) [RFC4862] to create an address might want to associate it with a name using DNS Dynamic Update (Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, “Dynamic Updates in the Domain Name System (DNS UPDATE),” April 1997.) [RFC2136] or DNS Secure Dynamic Update (Wellington, B., “Secure Domain Name System (DNS) Dynamic Update,” November 2000.) [RFC3007].

3.4.2.  Dynamic Host Configuration

As discussed in Section 3.2.2 (Internet Protocol Version 4) and Section 3.2.3 (Internet Protocol Version 6), IPv6 address assignment can be accomplished using either autoconfiguration, DHCP (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [RFC2131] or DHCPv6 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [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 which require 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, for the purpose of 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 (Mills, D., Martin, J., Burbank, J., and W. Kasch, “Network Time Protocol Version 4: Protocol and Algorithms Specification,” June 2010.) [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 (Simple Network Management Protocol (SNMP)), and NETCONF is discussed in Section 3.5.2 (Network Configuration (NETCONF) Protocol).

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:

• An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks (Harrington, D., Presuhn, R., and B. Wijnen, “An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks,” December 2002.) [RFC3411]
• Message Processing and Dispatching (Case, J., Harrington, D., Presuhn, R., and B. Wijnen, “Message Processing and Dispatching for the Simple Network Management Protocol (SNMP),” December 2002.) [RFC3412]
• SNMP Applications (Levi, D., Meyer, P., and B. Stewart, “Simple Network Management Protocol (SNMP) Applications,” December 2002.) [RFC3413]
• User-based Security Model (USM) for SNMP version 3 (Blumenthal, U. and B. Wijnen, “User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3),” December 2002.) [RFC3414]
• View-based Access Control Model (VACM) (Wijnen, B., Presuhn, R., and K. McCloghrie, “View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP),” December 2002.) [RFC3415]
• Version 2 of the SNMP Protocol Operations (Presuhn, R., “Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP),” December 2002.) [RFC3416]
• Transport Mappings (Presuhn, R., “Transport Mappings for the Simple Network Management Protocol (SNMP),” December 2002.) [RFC3417]
• Management Information Base (MIB) (Presuhn, R., “Management Information Base (MIB) for the Simple Network Management Protocol (SNMP),” December 2002.) [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:

• NETCONF Configuration Protocol (Enns, R., “NETCONF Configuration Protocol,” December 2006.) [RFC4741]
• Using the NETCONF Configuration Protocol over Secure SHell (SSH) (Wasserman, M. and T. Goddard, “Using the NETCONF Configuration Protocol over Secure SHell (SSH),” December 2006.) [RFC4742]
• Using NETCONF over the Simple Object Access Protocol (SOAP) (Goddard, T., “Using NETCONF over the Simple Object Access Protocol (SOAP),” December 2006.) [RFC4743]
• Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) (Lear, E. and K. Crozier, “Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP),” December 2006.) [RFC4744]
• NETCONF Event Notifications (Chisholm, S. and H. Trevino, “NETCONF Event Notifications,” July 2008.) [RFC5277]
• NETCONF over Transport Layer Security (TLS) (Badra, M., “NETCONF over Transport Layer Security (TLS),” May 2009.) [RFC5539]
• Partial Lock Remote Procedure Call (RPC) for NETCONF (Lengyel, B. and M. Bjorklund, “Partial Lock Remote Procedure Call (RPC) for NETCONF,” December 2009.) [RFC5717]

NETCONF was developed in response to operator requests for a common configuration protocol based on ASCII text as opposed to 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.

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 hostnames via multicast DNS (Cheshire, S. and M. Krochmal, “Multicast DNS,” March 2010.) [I‑D.cheshire‑dnsext‑multicastdns] and the automatic location of network services via DHCP (Dynamic Host Configuration), the DNS Service Discovery (DNS-SD) (Cheshire, S. and M. Krochmal, “DNS-Based Service Discovery,” March 2010.) [I‑D.cheshire‑dnsext‑dns‑sd] (part of Apple's Bonjour technology) and the Service Location Protocol (SLP) (Guttman, E., Perkins, C., Veizades, J., and M. Day, “Service Location Protocol, Version 2,” June 1999.) [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 discover protocols include:

Simplicity of creation and maintenance of resources

Commonly understood semantics

Conformance to existing and emerging standards

International scope and applicability

Extensibility

Interoperability among collections and indexing systems

The Constrained Application Protocol (CoAP) (Shelby, Z., Frank, B., and D. Sturek, “Constrained Application Protocol (CoAP),” September 2010.) [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] (Fielding, “Architectural Styles and the Design of Network-based Software Architectures,” 2000.), 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 discovery 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) (Cheshire, S. and M. Krochmal, “DNS-Based Service Discovery,” March 2010.) [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] (Nottingham, M. and E. Hammer-Lahav, “Defining Well-Known Uniform Resource Identifiers (URIs),” April 2010.). 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 several applications that are widely used but are not properly thought of as infrastructure.

3.7.1.  Session Initiation Protocol

The Session Initiation Protocol (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) [RFC3261][RFC3265] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.)[RFC3853] (Peterson, J., “S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP),” July 2004.)[RFC4320] (Sparks, R., “Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction,” January 2006.)[RFC4916] (Elwell, J., “Connected Identity in the Session Initiation Protocol (SIP),” June 2007.)[RFC5393] (Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, “Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies,” December 2008.)[RFC5621] (Camarillo, G., “Message Body Handling in the Session Initiation Protocol (SIP),” September 2009.) 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, the SDP: Session Description Protocol (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) [RFC4566] is intended for that purpose and to identify the actual endpoints' IP addresses. 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) (Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” July 2003.) [RFC3550] packets. This part is critical to understand because of the affect on NATs. Unless a NAT (with or without a firewall) is designed to be SDP aware (i.e., looking into each packet far enough to discover what the IP address and port number is for this particular session - and resetting it based on the Session Traversal Utilities for NAT (Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, “Session Traversal Utilities for NAT (STUN),” October 2008.) [RFC5389], the session established by SIP will not result in RTP packets being sent to the proper endpoint (in SIP called a user agent, or UA). It should be noted that SIP messaging has no issues with NATs, it is just the UA's inability to generally learn about the presence of the NATs that prevent the RTP packets from being received by the UA establishing the session.

3.7.2.  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) (Desruisseaux, B., “Internet Calendaring and Scheduling Core Object Specification (iCalendar),” September 2009.) [RFC5545] and is in the process of being updated to an XML schema in iCalendar XML Representation (Daboo, C., Douglass, M., and S. Lees, “xCal: The XML format for iCalendar,” October 2010.) [I‑D.daboo‑et‑al‑icalendar‑in‑xml] Several protocols exist to carry calendar events, including iCalendar Transport-Independent Interoperability Protocol (iTIP) (Daboo, C., “iCalendar Transport-Independent Interoperability Protocol (iTIP),” December 2009.) [RFC5546], the Message-Based Interoperability Protocol (iMIP) (Dawson, F., Mansour, S., and S. Silverberg, “iCalendar Message-Based Interoperability Protocol (iMIP),” November 1998.) [RFC2447] , and open source work on the Atom Publishing Protocol (Gregorio, J. and B. de hOra, “The Atom Publishing Protocol,” October 2007.) [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 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 (Conceptual model of Internet businesses).

            ------                  ------
           /      \                /      \
 /--\     /        \              /        \
|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 (Traceroute from residential customer to educational institution) passes through

• The home network,
• Cox Communications, an Access Network using Cable Modem technology,
• TransitRail, a commodity peering service for research and education (R&E) networks,
• Corporation for Education Network Initiatives in California (CENIC), a transit provider for educational networks, and
• 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  * * *

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 (Traceroute across VPN) 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] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) while other networks generally use public address space, and that three middleware technologies are in use here. These are the use 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 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:

• IP Multicast and Firewalls (Finlayson, R., “IP Multicast and Firewalls,” May 1999.) [RFC2588]
• Benchmarking Terminology for Firewall Performance (Newman, D., “Benchmarking Terminology for Firewall Performance,” August 1999.) [RFC2647]
• Behavior of and Requirements for Internet Firewalls (Freed, N., “Behavior of and Requirements for Internet Firewalls,” October 2000.) [RFC2979]
• Benchmarking Methodology for Firewall Performance (Hickman, B., Newman, D., Tadjudin, S., and T. Martin, “Benchmarking Methodology for Firewall Performance,” April 2003.) [RFC3511]
• Mobile IPv6 and Firewalls: Problem Statement (Le, F., Faccin, S., Patil, B., and H. Tschofenig, “Mobile IPv6 and Firewalls: Problem Statement,” May 2006.) [RFC4487]
• NAT and Firewall Traversal Issues of Host Identity Protocol Communication (Stiemerling, M., Quittek, J., and L. Eggert, “NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication,” April 2008.) [RFC5207]

Network Address Translation is a technology that was developed in response to ISP behaviors in the mid-1990's; when [RFC1918] (Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, “Address Allocation for Private Internets,” February 1996.) 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/aport 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:

• IP Network Address Translator Terminology and Considerations (Srisuresh, P. and M. Holdrege, “IP Network Address Translator (NAT) Terminology and Considerations,” August 1999.) [RFC2663]
• Traditional IP Network Address Translator (Srisuresh, P. and K. Egevang, “Traditional IP Network Address Translator (Traditional NAT),” January 2001.) [RFC3022]
• Protocol Complications with the IP Network Address Translator (Holdrege, M. and P. Srisuresh, “Protocol Complications with the IP Network Address Translator,” January 2001.) [RFC3027]
• Network Address Translator Friendly Application Design Guidelines (Senie, D., “Network Address Translator (NAT)-Friendly Application Design Guidelines,” January 2002.) [RFC3235]
• IAB Considerations for Network Address Translation (Daigle, L. and IAB, “IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation,” November 2002.) [RFC3424]
• IPsec-Network Address Translation Compatibility Requirements (Aboba, B. and W. Dixon, “IPsec-Network Address Translation (NAT) Compatibility Requirements,” March 2004.) [RFC3715]
• Network Address Translation Behavioral Requirements for Unicast UDP (Audet, F. and C. Jennings, “Network Address Translation (NAT) Behavioral Requirements for Unicast UDP,” January 2007.) [RFC4787]
• State of Peer-to-Peer Communication across Network Address Translators (Srisuresh, P., Ford, B., and D. Kegel, “State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs),” March 2008.) [RFC5128]
• IP Multicast Requirements for a Network Address Translator and a Network Address Port Translator (Wing, D. and T. Eckert, “IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT),” February 2008.) [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 (Traceroute across VPN), 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 (Rosen, E., Viswanathan, A., and R. Callon, “Multiprotocol Label Switching Architecture,” January 2001.) [RFC3031][RFC3032] (Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, “MPLS Label Stack Encoding,” January 2001.). .

5.  IANA Considerations

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.

6.  Security Considerations

Security is addressed in some detail in Section 2.2 (Security issues) and Section 3.1 (Security solutions).

7.  Acknowledgements

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.

8.  References

8.1. Normative References

8.2. Informative References

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 (The HAN, NAN, and Utility in the Advanced Metering Infrastructure) 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:

• How does Demand Response work? Either:
  • The utility presents pricing signals to the home,
  • The utility presents pricing signals individual devices (e.g., a Pluggable Electric Vehicle),
  • The utility adjusts settings on individual appliances within the home.
• 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 (Model 1: AMI with separated domains) 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 (Model 2: AMI with neighborhood access to the home) repeats the first example, but presuming that the utility directly accesses appliances within the HAN from the collector".
3. Appendix A.4 (Model 3: Collector is an IP router) 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 [1822] (Bolt Beranek and Newman Inc., “Interface Message Processor -- Specifications for the interconnection of a host and a IMP, Report No. 1822,” January 1976.). 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 (Homeplug), IEEE 802.15.4g (Zigbee), and IEEE 802.11 (WiFi, commonly deployed today and used by some high end appliances). 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 Secure 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.

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.

    Utility NAN
       /
      /
+----+-----+ +--+ +--+ +--+
|  Meter   | |D1| |D2| |D3|
+-----+----+ ++-+ ++-+ ++-+
      |       |    |    |
----+-+-------+----+----+---- IEEE 802.15.4
    |
 +--+---+
 |Router+------/------ Residential Broadband
 +--+---+
    |
----+---------+----+----+---- IEEE P1901
              |    |    |
             ++-+ ++-+ ++-+
             |D4| |D5| |D6|
             +--+ +--+ +--+

Figure 7 (Home Area Network) shows a simple network containing IEEE 802.15.4 and IEEE 1901 domains. It shows 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.

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 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 (Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.) [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 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 meter/ESI is just a node on the home network. 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., betweeen 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/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 obsess 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 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 (How to structure a network), 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 (The HAN, NAN, and Utility in the Advanced Metering Infrastructure) 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 (Home Area Network), 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, 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 OS 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.

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
              |    |    |
             ++-+ ++-+ ++-+
             |D4| |D5| |D6|
             +--+ +--+ +--+

In this case, as shown in Figure 8 (Home Area Network), 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 A.1.2 (HAN Security) 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 (Model 1: AMI with separated domains), 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] (Babiarz, J., Chan, K., and F. Baker, “Configuration Guidelines for DiffServ Service Classes,” August 2006.), 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 (Model 1: AMI with separated domains) or Appendix A.3 (Model 2: AMI with neighborhood access to the home); 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 A.3 (Model 2: AMI with neighborhood access to the home), there are serious security considerations in this model. Traffic being forwarded should be filtered, and the issues raised in Appendix A.1.2 (HAN Security) 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 (Model 1: AMI with separated domains), 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] (Babiarz, J., Chan, K., and F. Baker, “Configuration Guidelines for DiffServ Service Classes,” August 2006.), and let other traffic use the Standard Service Class or other service classes.

Authors' Addresses