[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 RFC 6272

Network Working Group                                           F. Baker
Internet-Draft                                                  D. Meyer
Intended status: Informational                             Cisco Systems
Expires: May 15, 2011                                  November 11, 2010


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

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 May 15, 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



Baker & Meyer             Expires May 15, 2011                  [Page 1]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  The Internet Protocol Suite  . . . . . . . . . . . . . . . . .  5
     2.1.  Internet Protocol Layers . . . . . . . . . . . . . . . . .  5
       2.1.1.  Application  . . . . . . . . . . . . . . . . . . . . .  6
       2.1.2.  Transport  . . . . . . . . . . . . . . . . . . . . . .  7
       2.1.3.  Network  . . . . . . . . . . . . . . . . . . . . . . .  7
         2.1.3.1.  Internet Protocol  . . . . . . . . . . . . . . . .  8
         2.1.3.2.  Lower layer networks . . . . . . . . . . . . . . .  8
       2.1.4.  Media layers: Physical and Link  . . . . . . . . . . .  8
     2.2.  Security issues  . . . . . . . . . . . . . . . . . . . . .  8
       2.2.1.  Physical security  . . . . . . . . . . . . . . . . . .  9
       2.2.2.  Network, Transport, and Application Layer Session
               Authentication . . . . . . . . . . . . . . . . . . . .  9
       2.2.3.  Confidentiality  . . . . . . . . . . . . . . . . . . . 10
     2.3.  Network Infrastructure . . . . . . . . . . . . . . . . . . 11
       2.3.1.  Domain Name System (DNS) . . . . . . . . . . . . . . . 11
       2.3.2.  Network Management . . . . . . . . . . . . . . . . . . 11
   3.  Specific protocols . . . . . . . . . . . . . . . . . . . . . . 11
     3.1.  Security solutions . . . . . . . . . . . . . . . . . . . . 12
       3.1.1.  Session identification, authentication,
               authorization, and accounting  . . . . . . . . . . . . 12
       3.1.2.  IP Security Architecture (IPsec) . . . . . . . . . . . 12
       3.1.3.  Transport Layer Security (TLS) . . . . . . . . . . . . 13
       3.1.4.  Secure/Multipurpose Internet Mail Extensions
               (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 14
     3.2.  Network Layer  . . . . . . . . . . . . . . . . . . . . . . 14
       3.2.1.  IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 14
         3.2.1.1.  Dual Stack Coexistence . . . . . . . . . . . . . . 14
         3.2.1.2.  Tunneling Mechanism  . . . . . . . . . . . . . . . 15
         3.2.1.3.  Translation between IPv4 and IPv6 Networks . . . . 15
       3.2.2.  Internet Protocol Version 4  . . . . . . . . . . . . . 16
         3.2.2.1.  IPv4 Address Allocation and Assignment . . . . . . 17
         3.2.2.2.  IPv4 Unicast Routing . . . . . . . . . . . . . . . 17
         3.2.2.3.  IPv4 Multicast Forwarding and Routing  . . . . . . 17
       3.2.3.  Internet Protocol Version 6  . . . . . . . . . . . . . 18
         3.2.3.1.  IPv6 Address Allocation and Assignment . . . . . . 18
         3.2.3.2.  IPv6 Routing . . . . . . . . . . . . . . . . . . . 19
       3.2.4.  Routing for IPv4 and IPv6  . . . . . . . . . . . . . . 19
         3.2.4.1.  Routing Information Protocol . . . . . . . . . . . 19
         3.2.4.2.  Open Shortest Path First . . . . . . . . . . . . . 20
         3.2.4.3.  ISO Intermediate System to Intermediate System . . 20
         3.2.4.4.  Border Gateway Protocol  . . . . . . . . . . . . . 20
         3.2.4.5.  Dynamic MANET On-demand (DYMO) Routing . . . . . . 21



Baker & Meyer             Expires May 15, 2011                  [Page 2]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


         3.2.4.6.  Optimized Link State Routing Protocol  . . . . . . 21
         3.2.4.7.  Routing for Low power and Lossy Networks . . . . . 21
       3.2.5.  IPv6 Multicast Forwarding and Routing  . . . . . . . . 22
         3.2.5.1.  Protocol-Independent Multicast Routing . . . . . . 22
       3.2.6.  Adaptation to lower layer networks and link layer
               protocols  . . . . . . . . . . . . . . . . . . . . . . 23
     3.3.  Transport Layer  . . . . . . . . . . . . . . . . . . . . . 23
       3.3.1.  User Datagram Protocol (UDP) . . . . . . . . . . . . . 24
       3.3.2.  Transmission Control Protocol (TCP)  . . . . . . . . . 24
       3.3.3.  Stream Control Transmission Protocol (SCTP)  . . . . . 25
       3.3.4.  Datagram Congestion Control Protocol (DCCP)  . . . . . 25
     3.4.  Infrastructure . . . . . . . . . . . . . . . . . . . . . . 26
       3.4.1.  Domain Name System . . . . . . . . . . . . . . . . . . 26
       3.4.2.  Dynamic Host Configuration . . . . . . . . . . . . . . 26
       3.4.3.  Network Time . . . . . . . . . . . . . . . . . . . . . 26
     3.5.  Network Management . . . . . . . . . . . . . . . . . . . . 26
       3.5.1.  Simple Network Management Protocol (SNMP)  . . . . . . 27
       3.5.2.  Network Configuration (NETCONF) Protocol . . . . . . . 27
     3.6.  Service and Resource Discovery . . . . . . . . . . . . . . 28
       3.6.1.  Service Discovery  . . . . . . . . . . . . . . . . . . 28
       3.6.2.  Resource Discovery . . . . . . . . . . . . . . . . . . 28
     3.7.  Other Applications . . . . . . . . . . . . . . . . . . . . 29
       3.7.1.  Session Initiation Protocol  . . . . . . . . . . . . . 29
       3.7.2.  Calendaring  . . . . . . . . . . . . . . . . . . . . . 30
   4.  A simplified view of the business architecture . . . . . . . . 30
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 35
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 35
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 35
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 35
   Appendix A.  Example: Advanced Metering Infrastructure . . . . . . 50
     A.1.  How to structure a network . . . . . . . . . . . . . . . . 52
       A.1.1.  HAN Routing  . . . . . . . . . . . . . . . . . . . . . 54
       A.1.2.  HAN Security . . . . . . . . . . . . . . . . . . . . . 54
     A.2.  Model 1: AMI with separated domains  . . . . . . . . . . . 56
     A.3.  Model 2: AMI with neighborhood access to the home  . . . . 56
     A.4.  Model 3: Collector is an IP router . . . . . . . . . . . . 57
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58












Baker & Meyer             Expires May 15, 2011                  [Page 3]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


1.  Introduction

   This document provides Smart Grid designers with advice on how to
   best "profile" the Internet Protocol Suite (IPS) for use in Smart
   Grids.  It provides an overview of the IPS and the key 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], the Stream Control Transmission Protocol
   (SCTP) [RFC4960], and the Datagram Congestion Control Protocol (DCCP)
   [RFC4340].  Another option is to select an encapsulation such as the
   User Datagram Protocol (UDP) [RFC0768] which essentially allows an
   application to implement its own transport service.  In practice, a
   designer will pick a transport protocol which is appropriate to the
   problem being solved.

   The IPS is standardized by the Internet Engineering Task Force
   (IETF).  IETF protocols are documented in the Request for Comment
   (RFC) series.  Several RFCs have been written describing how the IPS
   should be implemented.  These include:

   o  Requirements for Internet Hosts - Communication Layers [RFC1122],

   o  Requirements for Internet Hosts - Application and Support
      [RFC1123],

   o  Requirements for IP Version 4 Routers [RFC1812], and

   o  IPv6 Node Requirements [RFC4294],

   At this writing, RFC 4294 is in the process of being updated, in
   [I-D.ietf-6man-node-req-bis].

   This document is intended to provide Smart Grid architects and
   designers with a compendium of relevant RFCs (and to some extent
   Internet Drafts), and is organized as an annotated list of RFCs.  To
   that end, the remainder of this document is organized as follows:

   o  Section 2 describes the Internet Architecture and its protocol
      suite.

   o  Section 3 outlines the set of protocols that will be useful in
      Smart Grid deployment.





Baker & Meyer             Expires May 15, 2011                  [Page 4]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   o  Finally, Section 4 provides an overview of the business
      architecture embodied in the design and deployment of the IPS.


2.  The Internet Protocol Suite

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

2.1.  Internet Protocol Layers

   While Internet architecture uses the definitions and language similar
   to language used by the ISO Open System Interconnect Reference (ISO-
   OSI) Model (Figure 1), it actually predates that model.  As a result,
   there is some skew in terminology.  For example, the ISO-OSI model
   uses "end system" while the Internet architecture uses "host.
   Similarly, an "intermediate system" in the ISO-OSI model is called an
   "internet gateway" or "router" in Internet parlance.  Notwithstanding
   these differences, the fundamental concepts are largely the same.

                           +--------------------+
                           | Application Layer  |
                           +--------------------+
                           | Presentation Layer |
                           +--------------------+
                           | Session Layer      |
                           +--------------------+
                           | Transport layer    |
                           +--------------------+
                           | Network Layer      |
                           +--------------------+
                           | Data Link Layer    |
                           +--------------------+
                           | Physical Layer     |
                           +--------------------+

                   Figure 1: The ISO OSI Reference Model

   The structure of the Internet reference model is shown in Figure 2.











Baker & Meyer             Expires May 15, 2011                  [Page 5]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


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

                  Figure 2: The Internet Reference Model

2.1.1.  Application

   In the Internet model, the Application, Presentation, and Session
   layers are compressed into a single entity called "the application".
   For example, the Simple Network Management Protocol (SNMP) [RFC1157]
   describes an application that encodes its data in an ASN.1 profile
   and engages in a session to manage a network element.  The point here
   is that in the Internet the distinction between these layers exists
   but is not highlighted.  Further, note that in Figure 2 these
   functions are not necessarily cleanly layered: the fact that an
   application protocol encodes its data in some way and that it manages
   sessions in some way doesn't imply a hierarchy between those
   processes.  Rather, the application views encoding, session
   management, and a variety of other services as a tool set that it
   uses while doing its work.






Baker & Meyer             Expires May 15, 2011                  [Page 6]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


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] (an application layer
   protocol) as "the transport".

   In the Internet protocol stack, the "transport" is the lowest
   protocol layer that travels end-to-end unmodified, and is responsible
   for end-to-end data delivery services.  In the Internet the transport
   layer is the layer above the network layer.  Transport layer
   protocols have a single minimum requirement: the ability to multiplex
   several applications on one IP address.  UDP [RFC0768], TCP
   [RFC0793], DCCP [RFC4340], SCTP [RFC4960], and NORM [RFC5740] each
   accomplish this using a pair of port numbers, one for the sender and
   one for the receiver.  A port number identifies an application
   instance, which might be a general "listener" that peers or clients
   may open sessions with, or a specific correspondent with such a
   "listener".  The session identification in an IP datagram is often
   called the "five-tuple", and consists of the source and destination
   IP addresses, the source and destination ports, and an identifier for
   the transport protocol in use.

   In addition, the responsibilities of a specific transport layer
   protocol typically 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] or
   Asynchronous Transfer Mode (ATM), a path is set up once, and data is
   delivered through it.  In connectionless networks such as Ethernet
   and IP, data is delivered as datagrams.  Each datagram contains both
   the source and destination network layer addresses, and the network
   is responsible for delivering it.  In the Internet Protocol Suite,
   the Internet Protocol is the network that runs end to end.  It may be
   encapsulated over other LAN and WAN technologies, including both IP
   networks and networks of other types.




Baker & Meyer             Expires May 15, 2011                  [Page 7]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


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].  In
   addition, IP is also frequently carried in circuit networks such as
   MPLS [RFC4364], 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



Baker & Meyer             Expires May 15, 2011                  [Page 8]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   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.  Network, Transport, and Application Layer Session Authentication

   At the network, 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



Baker & Meyer             Expires May 15, 2011                  [Page 9]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   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) or TLS
   (Section 3.1.3), 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 is frequently a requirement for confidentiality.
   Confidentiality arises at several layers, sometimes simultaneously.
   For example, providers of credit card transaction services want



Baker & Meyer             Expires May 15, 2011                 [Page 10]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   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 decide 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.

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], which is XML-encoded and
   primarily used for device configuration.

   Another aspect of network management is the initial provisioning and
   configuration of hosts, which is discussed in Section 3.4.2.  Note
   that Smart Grid deployments may require identity authentication and
   authorization (as well as other provisioning and configuration) that
   may not be within the scope of either DHCP or Neighbor Discovery.
   While the IP Protocol Suite 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
   [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



Baker & Meyer             Expires May 15, 2011                 [Page 11]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   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), which protects
   IP datagrams, and Transport Layer Security (Section 3.1.3), which
   protects the information which the transport layer delivers.

3.1.2.  IP Security Architecture (IPsec)

   The Security Architecture for the Internet Protocol (IPsec) [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) [RFC4302] Encapsulating
   Security Payload (ESP) [RFC4303], Internet Key Exchange (IKEv2)
   [RFC5996], Cryptographic Algorithms [RFC4307], Cryptographic
   Algorithm Implementation Requirements for ESP and AH [RFC4835], and
   the use of Advanced Encryption Standard (AES) [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



Baker & Meyer             Expires May 15, 2011                 [Page 12]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   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 [RFC5246] and Datagram Transport Layer
   Security [RFC4347][I-D.ietf-tls-rfc4347-bis] 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, a 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:

   o  Key Establishment Algorithm

   o  Peer Authentication Algorithm

   o  Bulk Data Encryption Algorithm and key size

   o  Digest Algorithm

   Since each category 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.  Examples of the use of Cipher
   Suites include Elliptic Curve Cryptography (ECC)
   [RFC4492][RFC5289][I-D.mcgrew-tls-aes-ccm-ecc], Camellia [RFC5932],
   AES-CCM [I-D.mcgrew-tls-aes-ccm], and the Suite B Profile [RFC5430].
   [IEC62351-3] outlines the use of different TLS Cipher Suites for use
   in the Smart Grid.



Baker & Meyer             Expires May 15, 2011                 [Page 13]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   Used in conjunction with EAP-TLS [RFC5216], IEEE 802.1X [IEEE802.1X]
   is a widely deployed mechanism providing access security for wired or
   wireless IEEE 802 LANs.  Protocol for Carrying Authentication for
   Network Access (PANA) [RFC5193] is also gaining traction, as Zigbee
   IP has chosen PANA using EAP-TLS for network access security.

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

   The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049]
   [RFC5750] [RFC5751] [RFC4262] 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].

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.

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
   [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

   o  provide a network that routes both IPv4 and IPv6,





Baker & Meyer             Expires May 15, 2011                 [Page 14]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   o  ensure that servers similarly support both protocols, and

   o  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 [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)
   [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:

   o  Framework for IPv4/IPv6 Translation
      [I-D.ietf-behave-v6v4-framework]

   o  IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]

   o  DNS extensions [I-D.ietf-behave-dns64]





Baker & Meyer             Expires May 15, 2011                 [Page 15]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   o  IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate]

   o  Translation from IPv6 Clients to IPv4 Servers
      [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 [RFC0791] and the Internet Control Message Protocol [RFC0792]
   comprise the IPv4 network layer.  IPv4 provides unreliable delivery
   of datagrams.

   IPv4 also provides for fragmentation and reassembly of long datagrams
   for transmission through networks with small Maximum Transmission
   Units (MTU).  The MTU is the largest packet size that can be
   delivered across the network.  In addition, the IPS provides the
   Internet Control Message Protocol (ICMP) [RFC0792], which is a
   separate protocol that enables the network to report errors and other
   issues to hosts that originate problematic datagrams.

   IPv4 originally supported an experimental type of service field that
   identified eight levels of operational precedence styled after the
   requirements of military telephony, plus three and later four bit



Baker & Meyer             Expires May 15, 2011                 [Page 16]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2
   [RFC2328] interpreted as control traffic; this control traffic is
   assured of not being dropped when queued or upon receipt even if
   other traffic is being dropped..  These control bits turned out to be
   less useful than the designers had hoped.  They were replaced by the
   Differentiated Services Architecture [RFC2474][RFC2475], which
   contains a six bit code point used to select an algorithm (a "per-hop
   behavior") to be applied to the datagram.  The IETF has also produced
   a set of Configuration Guidelines for DiffServ Service Classes
   [RFC4594], which describes a set of service classes that may be
   useful to a network operator.

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) [RFC2131].  On most interface types, neighboring equipment
   identify each other's addresses using Address Resolution Protocol
   (ARP) [RFC0826].

3.2.2.2.  IPv4 Unicast Routing

   Routing for the IPv4 Internet is accomplished by routing applications
   that exchange connectivity information and build semi-static
   destination routing databases.  If a datagram is directed to a given
   destination address, the address is looked up in the routing
   database, and the most specific ("longest") prefix found that
   contains it is used to identify the next hop router, or the end
   system 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 [RFC2453], OSI
   IS-IS for IPv4 [RFC1195], OSPF Version 2 [RFC2328], and BGP-4
   [RFC4271].  Active research exists in mobile ad hoc routing and other
   routing paradigms; these result in new protocols and modified
   forwarding paradigms.

3.2.2.3.  IPv4 Multicast Forwarding and Routing

   IPv4 was originally specified as a unicast (point to point) protocol,
   and was extended to support multicast in [RFC1112].  This uses the
   Internet Group Management Protocol [RFC3376][RFC4604] to enable
   applications to join multicast groups, and for most applications uses
   Source-Specific Multicast [RFC4607] for routing and delivery of
   multicast messages.

   An experiment carried out in IPv4 that is not part of the core



Baker & Meyer             Expires May 15, 2011                 [Page 17]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   Internet architecture but may be of interest in the Smart Grid is the
   development of so-called "Reliable Multicast".  This is "so-called"
   because it is not "reliable" in the strict sense of the word - it is
   perhaps better described as "enhanced reliability".  A best effort
   network by definition can lose traffic, duplicate it, or reorder it,
   something as true for multicast as for unicast.  Research in
   "Reliable Multicast" technology intends to improve the probability of
   delivery of multicast traffic.

   In that research, the IETF imposed guidelines [RFC2357] on the
   research community regarding what was desirable.  Important results
   from that research include a number of papers and several proprietary
   protocols including some that have been used in support of business
   operations.  RFCs in the area include The Use of Forward Error
   Correction (FEC) in Reliable Multicast [RFC3453], the Negative-
   acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
   [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP)
   [RFC4410].  These are considered experimental.

3.2.3.  Internet Protocol Version 6

   IPv6 [RFC2460], with the Internet Control Message Protocol "v6"
   [RFC4443], constitutes the next generation protocol for the Internet.
   IPv6 provides for transmission of datagrams from source to
   destination hosts, which are identified by fixed length addresses.

   IPv6 also provides for fragmentation and reassembly of long datagrams
   by the originating host, if necessary, for transmission through
   "small packet" networks.  ICMPv6, which is a separate protocol
   implemented along with IPv6, enables the network to report errors and
   other issues to hosts that originate problematic datagrams.

   IPv6 adopted the Differentiated Services Architecture
   [RFC2474][RFC2475], which contains a six bit code point used to
   select an algorithm (a "per-hop behavior") to be applied to the
   datagram.

   The IPv6 over Low-Power Wireless Personal Area Networks [RFC4919] RFC
   and the Compression Format for IPv6 Datagrams in 6LoWPAN Networks
   [I-D.ietf-6lowpan-hc] addresses IPv6 header compression and subnet
   architecture in at least some sensor networks, and may be appropriate
   to the Smart Grid Advanced Metering Infrastructure or other sensor
   domains.

3.2.3.1.  IPv6 Address Allocation and Assignment

   An IPv6 Address [RFC4291] may be administratively assigned using
   DHCPv6 [RFC3315] in a manner similar to the way IPv4 addresses are.



Baker & Meyer             Expires May 15, 2011                 [Page 18]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   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] and [RFC4941].
   IPv6 neighbors identify each other's addresses using either Neighbor
   Discovery (ND) [RFC4861] or SEcure Neighbor Discovery (SEND)
   [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 [RFC2080],
   IS-IS for IPv6 [RFC5308], OSPF for IPv6 [RFC5340], and BGP-4 for IPv6
   [RFC2545].  Active research exists in mobile ad hoc routing, routing
   in low power networks (sensors and smart grids) and other routing
   paradigms; these result in new protocols and modified forwarding
   paradigms.

3.2.4.  Routing for IPv4 and IPv6

3.2.4.1.  Routing Information Protocol

   The prototypical routing protocol used in the Internet has probably
   been the Routing Information Protocol [RFC1058].  People that use it
   today tend to deploy RIPng for IPv6 [RFC2080] and RIP Version 2
   [RFC2453].  Briefly, RIP is a distance vector routing protocol that
   is based on a distributed variant of the widely known Bellman-Ford
   algorithm.  In distance vector routing protocols, each router
   announces the contents of its route table to neighboring routers,
   which integrate the results with their route tables and re-announce
   them to others.  It has been characterized as "routing by rumor", and
   suffers many of the ills we find in human gossip - propagating stale
   or incorrect information in certain failure scenarios, and being in
   cases unresponsive to changes in topology.  [RFC1058] provides
   guidance to algorithm designers to mitigate these issues.







Baker & Meyer             Expires May 15, 2011                 [Page 19]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


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 [RFC2328] for IPv4, OSPF for IPv6
   [RFC5340] for IPv6, and the Support of Address Families in OSPFv3
   [RFC5838] to enable [RFC5340] to route both IPv4 and IPv6.

   The advantage of any SPF-based protocol (i.e., OSPF and IS-IS) is
   primarily that every router in the network constructs its view of the
   network from first hand knowledge rather than the "gossip" that
   distance vector protocols propagate.  As such, the topology is
   quickly and easily changed by simply announcing the change.  The
   disadvantage of SPF-based protocols is that each router must store a
   first-person statement of the connectivity of each router in the
   domain.

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 [RFC1195], and more recently
   for routing of IPv6 [RFC5308].

   As with OSPF, the positives of any SPF-based protocol and
   specifically IS-IS are primarily that the network is described as a
   lattice of routers with connectivity to subnets and isolated hosts.
   It's topology is quickly and easily changed by simply announcing the
   change, without the issues of "routing by rumor", since every host
   within the routing domain has a first-person statement of the
   connectivity of each router in the domain.  The negatives are a
   corollary: each router must store a first-person statement of the
   connectivity of each router in the domain.

3.2.4.4.  Border Gateway Protocol

   The Border Gateway Protocol (BGP) [RFC4271] is widely used in the
   IPv4 Internet to exchange routes between administrative entities -
   service providers, their peers, their upstream networks, and their
   customers - while applying specific policy.  Multi-protocol
   Extensions [RFC4760] to BGP allow BGP to carry IPv6 Inter-Domain
   Routing [RFC2545], multicast reachability information, and VPN
   information, among others.

   Considerations that apply with BGP deal with the flexibility and



Baker & Meyer             Expires May 15, 2011                 [Page 20]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   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
   [RFC3561].  This protocol captured the minds of some in the embedded
   devices industry, but experienced issues in wireless networks such as
   802.15.4 and 802.11's Ad Hoc mode.  As a result, it is in the process
   of being updated in the Dynamic MANET On-demand (DYMO) Routing
   [I-D.ietf-manet-dymo] protocol.

   AODV and DYMO are essentially reactive routing protocols designed for
   mobile ad hoc networks, and usable in other forms of ad hoc networks.
   They provide connectivity between a device within a distributed
   subnet and a few devices (including perhaps a gateway or router to
   another subnet) without tracking connectivity to other devices.  In
   essence, routing is calculated and discovered upon need, and a host
   or router need only maintain the routes that currently work and are
   needed.

3.2.4.6.  Optimized Link State Routing Protocol

   The Optimized Link State Routing Protocol (OLSR) [RFC3626] is a
   proactive routing protocol designed for mobile ad hoc networks, and
   can be used in other forms of ad hoc networks.  It provides arbitrary
   connectivity between 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] is a reactive routing protocol designed for use
   in resource constrained networks.  Requirements for resource
   constrained networks are defined in [RFC5548], [RFC5673], [RFC5826],
   and [RFC5867].

   Briefly, a constrained network is comprised of nodes that:

   o  Are built with limited processing power and memory, and sometimes
      energy when operating on batteries.




Baker & Meyer             Expires May 15, 2011                 [Page 21]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   o  Are interconnected through a low-data-rate network interface and
      potentially vulnerable to communication instability and low packet
      delivery rates.

   o  Potentially have a mix of roles such as being able to act as a
      host (i.e., generating traffic) and/or a router (i.e., both
      forwarding and generating RPL traffic).

3.2.5.  IPv6 Multicast Forwarding and Routing

   IPv6 specifies both unicast and multicast datagram exchange.  This
   uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710]
   [RFC3590] [RFC3810] [RFC4604] to enable applications to join
   multicast groups, and for most applications uses Source-Specific
   Multicast [RFC4607] for routing and delivery of multicast messages.

   The mechanisms experimentally developed for reliable multicast in
   IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well.

3.2.5.1.  Protocol-Independent Multicast Routing

   A multicast routing protocol has two basic functions: Building the
   multicast distribution tree and forwarding multicast traffic.
   Multicast routing protocols generally contain a control plane for
   building distribution trees, and a forwarding plane that uses the
   distribution tree when forwarding multicast traffic.

   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) [RFC3973] and Protocol Independent Multicast
   - Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601]
   were designed for the ASM model.

   Many modern multicast deployments use Source-Specific Multicast (PIM-
   SSM) [RFC3569][RFC4608].  In the SSM model, a host expresses interest
   in a "channel", which is comprised of a source (S) and a group (G).
   Distribution trees are rooted to the sending host (called an "(S,G)
   tree").  Since only the source S can send on to the group, SSM has



Baker & Meyer             Expires May 15, 2011                 [Page 22]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   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].  IPv6 does the same
      using [RFC2464].

   PPP:  The IETF has defined a serial line protocol, the Point-to-Point
      Protocol (PPP) [RFC1661], that uses HDLC (bit-synchronous or byte
      synchronous) framing.  The IPv4 adaptation specification is
      [RFC1332], and the IPv6 adaptation specification is [RFC5072].
      Current use of this protocol is in traditional serial lines,
      authentication exchanges in DSL networks using PPP Over Ethernet
      (PPPoE) [RFC2516], and in the Digital Signaling Hierarchy
      (generally referred to as Packet-on-SONET/SDH) using PPP over
      SONET/SDH [RFC2615].

   IEEE 802.15.4:  The adaptation specification for IPv6 transmission
      over IEEE 802.15.4 Networks is [RFC4944].

   Numerous other adaptation specifications exist, including ATM, Frame
   Relay, X.25, other standardized and proprietary LAN technologies, and
   others.

3.3.  Transport Layer

   This section outlines the functionality of UDP, TCP, SCTP, and DCCP.
   UDP and TCP are best known and most widely used in the Internet
   today, while SCTP and DCCP are newer protocols that built for
   specific purposes.  Other transport protocols can be built when
   required.




Baker & Meyer             Expires May 15, 2011                 [Page 23]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


3.3.1.  User Datagram Protocol (UDP)

   The User Datagram Protocol [RFC0768] and the Lightweight User
   Datagram Protocol [RFC3828] are properly not "transport" protocols in
   the sense of "a set of rules governing the exchange or transmission
   of data electronically between devices".  They are labels that
   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 [RFC5405].

   Datagram Transport Layer Security [RFC5238] can be used to prevent
   eavesdropping, tampering, or message forgery for applications that
   run over UDP.  Alternatively, UDP can run over IPsec.

3.3.2.  Transmission Control Protocol (TCP)

   TCP [RFC0793] is the predominant transport protocol in use in the
   Internet.  It is "reliable", as the term is used in protocol design:
   it delivers data to its peer and provides acknowledgement to the
   sender, or it dies trying.  It has extensions for Congestion Control
   [RFC5681] and Explicit Congestion Notification [RFC3168].

   The user interface for TCP is a byte stream interface - an
   application using TCP might "write" to it several times only to have
   the data compacted into a common segment and delivered as such to its
   peer.  For message-stream interfaces, we generally use the ISO
   Transport Service on TCP [RFC1006][RFC2126] in the application.

   Transport Layer Security [RFC5246] can be used to prevent
   eavesdropping, tampering, or message forgery.  Alternatively, TCP can
   run over IPsec.  Additionally, [RFC4987] discusses mechanisms similar
   to SCTP and DCCP's "cookie" approach that may be used to secure TCP
   sessions against flooding attacks.

   Finally, note that TCP has been the subject of ongoing research and
   development since it was written.  The End to End research group has
   published a Roadmap for TCP Specification Documents [RFC4614] to
   capture this history, to guide TCP implementors, and provide context
   for TCP researchers.







Baker & Meyer             Expires May 15, 2011                 [Page 24]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


3.3.3.  Stream Control Transmission Protocol (SCTP)

   SCTP [RFC4960] is a more recent reliable transport protocol that can
   be imagined as a TCP-like context containing multiple separate and
   independent message streams (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 [RFC5061], enabling peers to change addresses
   during the session and yet retain connectivity.  Transport Layer
   Security [RFC3436] can be used to prevent eavesdropping, tampering,
   or message forgery.  Alternatively, SCTP can run over IPsec.

3.3.4.  Datagram Congestion Control Protocol (DCCP)

   DCCP [RFC4340] is an "unreliable" transport protocol (e.g., one that
   does not guarantee message delivery) that provides bidirectional
   unicast connections of congestion-controlled unreliable datagrams.
   DCCP is suitable for applications that transfer fairly large amounts
   of data and that can benefit from control over the tradeoff between
   timeliness and reliability.

   DCCP implements a simple "cookie" mechanism intended to limit the
   effectiveness of flooding attacks by mutual authentication.  This
   demonstrates that the application is connected to the same peer, but
   does not identify the peer.  Datagram Transport Layer Security
   [RFC5238] can be used to prevent eavesdropping, tampering, or message
   forgery.  Alternatively, DCCP can run over IPsec.







Baker & Meyer             Expires May 15, 2011                 [Page 25]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


3.4.  Infrastructure

3.4.1.  Domain Name System

   In order to facilitate network management and operations, the
   Internet Community has defined the Domain Name System (DNS)
   [RFC1034][RFC1035].  Names are hierarchical: a name like example.com
   is found registered with a .com registrar, and within the associated
   network other names like baldur.cincinatti.example.com can be
   defined, with obvious hierarchy.  Security extensions, which allow a
   registry to sign the records it contains and as a result demonstrate
   their authenticity, are defined by the DNS Security Extensions
   [RFC4033][RFC4034][RFC4035].

   Devices can also optionally update their own DNS record.  For
   example, a sensor that is using Stateless Address Autoconfiguration
   [RFC4862] to create an address might want to associate it with a name
   using DNS Dynamic Update [RFC2136] or DNS Secure Dynamic Update
   [RFC3007].

3.4.2.  Dynamic Host Configuration

   As discussed in Section 3.2.2, IPv4 address assignment is generally
   performed using DHCP [RFC2131].  By contrast, Section 3.2.3 points
   out that IPv6 address assignment can be accomplished using either
   autoconfiguration [RFC4862][RFC4941] or DHCPv6 [RFC3315].  The best
   argument for the use of autoconfiguration is a large number of
   systems that require little more than a random number as an address;
   the argument for DHCP is administrative control.

   There are other parameters that may need to be allocated to hosts
   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 [RFC5905].

3.5.  Network Management

   The IETF has developed two protocols for network management: SNMP and
   NETCONF.  SNMP is discussed in Section 3.5.1, and NETCONF is
   discussed in Section 3.5.2.



Baker & Meyer             Expires May 15, 2011                 [Page 26]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


3.5.1.  Simple Network Management Protocol (SNMP)

   The Simple Network Management Protocol, originally specified in the
   late 1980's and having passed through several revisions, is specified
   in several documents:

   o  An Architecture for Describing Simple Network Management Protocol
      (SNMP) Management Frameworks [RFC3411]

   o  Message Processing and Dispatching [RFC3412]

   o  SNMP Applications [RFC3413]

   o  User-based Security Model (USM) for SNMP version 3 [RFC3414]

   o  View-based Access Control Model (VACM) [RFC3415]

   o  Version 2 of the SNMP Protocol Operations [RFC3416]

   o  Transport Mappings [RFC3417]

   o  Management Information Base (MIB) [RFC3418]

   It provides capabilities for polled and event-driven activities, and
   for both monitoring and configuration of systems in the field.
   Historically, it has been used primarily for monitoring nodes in a
   network.  Messages and their constituent data are encoded using a
   profile of ASN.1.

3.5.2.  Network Configuration (NETCONF) Protocol

   The NETCONF Configuration Protocol is specified in one basic
   document, with supporting documents for carrying it over the IPS.
   These documents include:

   o  NETCONF Configuration Protocol [RFC4741]

   o  Using the NETCONF Configuration Protocol over Secure SHell (SSH)
      [RFC4742]

   o  Using NETCONF over the Simple Object Access Protocol (SOAP)
      [RFC4743]

   o  Using the NETCONF Protocol over the Blocks Extensible Exchange
      Protocol (BEEP) [RFC4744]

   o  NETCONF Event Notifications [RFC5277]




Baker & Meyer             Expires May 15, 2011                 [Page 27]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   o  NETCONF over Transport Layer Security (TLS) [RFC5539]

   o  Partial Lock Remote Procedure Call (RPC) for NETCONF [RFC5717]

   NETCONF was developed in response to operator requests for a common
   configuration protocol based on ASCII text 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
   [I-D.cheshire-dnsext-multicastdns] and the automatic location of
   network services via DHCP (Section 3.4.2), the DNS Service Discovery
   (DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part of Apple's Bonjour
   technology) and the Service Location Protocol (SLP) [RFC2608].

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




Baker & Meyer             Expires May 15, 2011                 [Page 28]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


      International scope and applicability

      Extensibility

      Interoperability among collections and indexing systems

   The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is
   being developed in IETF with these goals in mind.  In particular,
   CoAP is designed for use in constrained resource networks and for
   machine-to-machine applications such as smart energy and building
   automation.  It provides a RESTful transfer protocol [RESTFUL], a
   built-in resource discovery protocol, and includes web concepts such
   as URIs and content-types.  CoAP provides both unicast and multicast
   resource discovery and includes the ability to filter on attributes
   of resource descriptions.  Finally, CoAP resource discovery can also
   be used to discover HTTP resources.

   For simplicity, CoAP makes the assumption that all CoAP servers
   listen on the default CoAP port or otherwise have been configured or
   discovered using some general service discovery mechanism such as DNS
   Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd].

   Resource discovery in CoAP is accomplished through the use of well-
   known resources which describe the links offered by a CoAP server.
   CoAP defines a well-known URI for discovery: "/.well-known/r"
   [RFC5785].  For example, the query [GET /.well-known/r] returns a
   list of links (representing resources) available from the queried
   CoAP server.  A query such as [GET /.well-known/r?n=Voltage] returns
   the resources with the name Voltage.

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
   [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is an
   application layer control (signaling) protocol for creating,
   modifying and terminating multimedia sessions on the Internet, meant
   to be more scalable than H.323.  Multimedia sessions can be voice,
   video, instant messaging, shared data, and/or subscriptions of
   events.  SIP can run on top of TCP, UDP, SCTP, or TLS over TCP.  SIP
   is independent of the transport layer, and independent of the
   underlying IPv4/v6 version.  In fact, the transport protocol used can
   change as the SIP message traverses SIP entities from source to
   destination.



Baker & Meyer             Expires May 15, 2011                 [Page 29]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   SIP itself does not choose whether a session is voice or video, the
   SDP: Session Description Protocol [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)
   [RFC3550] packets.  This part is critical to understand because of
   the affect on Network Address Translators, or 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 [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)
   [RFC5545] and is in the process of being updated to an XML schema in
   iCalendar XML Representation [I-D.daboo-et-al-icalendar-in-xml]
   Several protocols exist to carry calendar events, including iCalendar
   Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the
   Message-Based Interoperability Protocol (iMIP) [RFC2447] , and open
   source work on the Atom Publishing Protocol [RFC5023].


4.  A simplified view of the business architecture

   The Internet is a network of networks in which networks are
   interconnected in specific ways and are independently operated.  It
   is important to note that the underlying Internet architecture puts
   no restrictions on the ways that networks are interconnected;
   interconnection is a business decision.  As such, the Internet
   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



Baker & Meyer             Expires May 15, 2011                 [Page 30]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   divided into "Enterprise Networks" and "Access Networks"; Enterprise
   networks provide "free" connectivity to their own employees or
   members, and also provide them a set of services including electronic
   mail, web services, and so on.  Access Networks sell broadband
   connectivity (DSL, Cable Modem, 802.11 wireless or 3GPP wireless), or
   "dial" services including PSTN dial-up and ISDN, to subscribers.  The
   subscribers are typically either residential or small office/home
   office (SOHO) customers.  Residential customers are generally
   entirely dependent on their access provider for all services, while a
   SOHO buys some services from the access provider and may provide
   others for itself.  Networks that sell transit services to nobody
   else - SOHO, residential, and enterprise networks - are generally
   refereed to as "edge networks"; Transit Networks are considered to be
   part of the "core" of the Internet, and access networks are between
   the two.  This general structure is depicted in Figure 3.

                           ------                  ------
                          /      \                /      \
                /--\     /        \              /        \
               |SOHO|---+  Access  |            |Enterprise|
                \--/    |  Service |            | Network  |
                /--\    |  Provider|            |          |
               |Home|---+          |   ------   |          |
                \--/     \        +---+      +---+        /
                          \      /   /        \   \      /
                           ------   | Transit  |   ------
                                    | Service  |
                                    | Provider |
                                    |          |
                                     \        /
                                      \      /
                                       ------

             Figure 3: Conceptual model of Internet businesses

   A specific example is shown in a traceroute from a home to a nearby
   school.  Internet connectivity in Figure 4 passes through

   o  The home network,

   o  Cox Communications, an Access Network using Cable Modem
      technology,

   o  TransitRail, a commodity peering service for research and
      education (R&E) networks,

   o  Corporation for Education Network Initiatives in California
      (CENIC), a transit provider for educational networks, and



Baker & Meyer             Expires May 15, 2011                 [Page 31]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   o  the University of California at Santa Barbara, which in this
      context might be viewed as an access network for its students and
      faculty or as an enterprise network.


     <stealth-10-32-244-218:> fred% traceroute www.ucsb.edu
     traceroute to web.ucsb.edu (128.111.24.41),
             64 hops max, 40 byte packets
      1  fred-vpn (10.32.244.217)  1.560 ms  1.108 ms  1.133 ms
      2  wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1)  12.540 ms  ...
      3  68.6.13.101 ...
      4  68.6.13.129 ...
      5  langbbr01-as0.r2.la.cox.net ...
      6  calren46-cust.lsanca01.transitrail.net ...
      7  dc-lax-core1--lax-peer1-ge.cenic.net ...
      8  dc-lax-agg1--lax-core1-ge.cenic.net ...
      9  dc-ucsb--dc-lax-dc2.cenic.net ...
     10  r2--r1--1.commserv.ucsb.edu ...
     11  574-c--r2--2.commserv.ucsb.edu ...
     12  * * *

       Figure 4: Traceroute from residential customer to educational
                                institution

   Another specific example could be shown in a traceroute from the home
   through a Virtual Private Network (VPN tunnel) from the home,
   crossing Cox Cable (an Access Network) and Pacific Bell (a Transit
   Network), and terminating in Cisco Systems (an Enterprise Network); a
   traceroute of the path doesn't show that as it is invisible within
   the VPN and the contents of the VPN are invisible, due to encryption,
   to the networks on the path.  Instead, the traceroute in Figure 5 is
   entirely within Cisco's internal network.

         <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 ...




Baker & Meyer             Expires May 15, 2011                 [Page 32]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


                      Figure 5: Traceroute across VPN

   Note that in both cases, the home network uses private address space
   [RFC1918] while other networks generally use public address space,
   and that three middleware technologies are in use here.  These are
   the 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:

   o  IP Multicast and Firewalls [RFC2588]

   o  Benchmarking Terminology for Firewall Performance [RFC2647]

   o  Behavior of and Requirements for Internet Firewalls [RFC2979]

   o  Benchmarking Methodology for Firewall Performance [RFC3511]

   o  Mobile IPv6 and Firewalls: Problem Statement [RFC4487]





Baker & Meyer             Expires May 15, 2011                 [Page 33]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   o  NAT and Firewall Traversal Issues of Host Identity Protocol
      Communication [RFC5207]

   Network Address Translation is a technology that was developed in
   response to ISP behaviors in the mid-1990's; when [RFC1918] was
   published, many ISPs started handing out single or small numbers of
   addresses, and edge networks were forced to translate.  In time, this
   became considered a good thing, or at least not a bad thing; it
   amplified the public address space, and it was sold as if it were a
   firewall.  It of course is not; while traditional dynamic NATs only
   translate between internal and external session address/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:

   o  IP Network Address Translator Terminology and Considerations
      [RFC2663]

   o  Traditional IP Network Address Translator [RFC3022]

   o  Protocol Complications with the IP Network Address Translator
      [RFC3027]

   o  Network Address Translator Friendly Application Design Guidelines
      [RFC3235]

   o  IAB Considerations for Network Address Translation [RFC3424]

   o  IPsec-Network Address Translation Compatibility Requirements
      [RFC3715]

   o  Network Address Translation Behavioral Requirements for Unicast
      UDP [RFC4787]

   o  State of Peer-to-Peer Communication across Network Address
      Translators [RFC5128]

   o  IP Multicast Requirements for a Network Address Translator and a
      Network Address Port Translator [RFC5135]

   Virtual Private Networks come in many forms; what they have in common
   is that they are generally tunneled over the internet backbone, so
   that as in Figure 5, connectivity appears to be entirely within the
   edge network although it is in fact across a service provider's
   network.  Examples include IPsec tunnel-mode encrypted tunnels, IP-
   in-IP or GRE tunnels and MPLS LSPs [RFC3031][RFC3032]. .




Baker & Meyer             Expires May 15, 2011                 [Page 34]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


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 and Section 3.1.


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

   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
              Communication Layers", STD 3, RFC 1122, October 1989.

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
              RFC 1812, June 1995.

   [RFC4294]  Loughney, J., "IPv6 Node Requirements", RFC 4294,
              April 2006.

8.2.  Informative References

   [1822]     Bolt Beranek and Newman Inc., "Interface Message Processor
              -- Specifications for the interconnection of a host and a



Baker & Meyer             Expires May 15, 2011                 [Page 35]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


              IMP, Report No. 1822", January 1976.

   [I-D.arkko-ipv6-transition-guidelines]
              Arkko, J. and F. Baker, "Guidelines for Using IPv6
              Transition Mechanisms during IPv6 Deployment",
              draft-arkko-ipv6-transition-guidelines-08 (work in
              progress), November 2010.

   [I-D.cheshire-dnsext-dns-sd]
              Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", draft-cheshire-dnsext-dns-sd-07 (work in
              progress), October 2010.

   [I-D.cheshire-dnsext-multicastdns]
              Cheshire, S. and M. Krochmal, "Multicast DNS",
              draft-cheshire-dnsext-multicastdns-12 (work in progress),
              October 2010.

   [I-D.daboo-et-al-icalendar-in-xml]
              Daboo, C., Douglass, M., and S. Lees, "xCal: The XML
              format for iCalendar",
              draft-daboo-et-al-icalendar-in-xml-07 (work in progress),
              October 2010.

   [I-D.ietf-6lowpan-hc]
              Hui, J. and P. Thubert, "Compression Format for IPv6
              Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-13
              (work in progress), September 2010.

   [I-D.ietf-6man-node-req-bis]
              Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
              Requirements RFC 4294-bis",
              draft-ietf-6man-node-req-bis-06 (work in progress),
              October 2010.

   [I-D.ietf-behave-dns64]
              Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
              "DNS64: DNS extensions for Network Address Translation
              from IPv6 Clients to IPv4 Servers",
              draft-ietf-behave-dns64-11 (work in progress),
              October 2010.

   [I-D.ietf-behave-v6v4-framework]
              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation",
              draft-ietf-behave-v6v4-framework-10 (work in progress),
              August 2010.




Baker & Meyer             Expires May 15, 2011                 [Page 36]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   [I-D.ietf-behave-v6v4-xlate]
              Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
              Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in
              progress), September 2010.

   [I-D.ietf-behave-v6v4-xlate-stateful]
              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers",
              draft-ietf-behave-v6v4-xlate-stateful-12 (work in
              progress), July 2010.

   [I-D.ietf-core-coap]
              Shelby, Z., Frank, B., and D. Sturek, "Constrained
              Application Protocol (CoAP)", draft-ietf-core-coap-03
              (work in progress), October 2010.

   [I-D.ietf-manet-dymo]
              Chakeres, I. and C. Perkins, "Dynamic MANET On-demand
              (DYMO) Routing", draft-ietf-manet-dymo-21 (work in
              progress), July 2010.

   [I-D.ietf-roll-rpl]
              Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
              Vasseur, "RPL: IPv6 Routing Protocol for Low power and
              Lossy Networks", draft-ietf-roll-rpl-15 (work in
              progress), November 2010.

   [I-D.ietf-tls-rfc4347-bis]
              Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security version 1.2", draft-ietf-tls-rfc4347-bis-04 (work
              in progress), July 2010.

   [I-D.mcgrew-tls-aes-ccm]
              McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for TLS",
              draft-mcgrew-tls-aes-ccm-00 (work in progress), June 2010.

   [I-D.mcgrew-tls-aes-ccm-ecc]
              McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES-
              CCM ECC Cipher Suites for TLS",
              draft-mcgrew-tls-aes-ccm-ecc-00 (work in progress),
              July 2010.

   [IEC62351-3]
              International Electrotechnical Commission Technical
              Committee 57, "POWER SYSTEMS MANAGEMENT AND ASSOCIATED
              INFORMATION EXCHANGE. DATA AND COMMUNICATIONS SECURITY --



Baker & Meyer             Expires May 15, 2011                 [Page 37]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


              Part 3: Communication network and system security Profiles
              including TCP/IP", May 2007.

   [IEEE802.1X]
              Institute of Electrical and Electronics Engineers, "IEEE
              Standard for Local and Metropolitan Area Networks - Port
              based Network Access Control", IEEE Standard 802.1X-2010,
              February 2010.

   [RESTFUL]  Fielding, "Architectural Styles and the Design of Network-
              based Software Architectures", 2000.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, September 1981.

   [RFC0826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
              converting network protocol addresses to 48.bit Ethernet
              address for transmission on Ethernet hardware", STD 37,
              RFC 826, November 1982.

   [RFC0894]  Hornig, C., "Standard for the transmission of IP datagrams
              over Ethernet networks", STD 41, RFC 894, April 1984.

   [RFC1006]  Rose, M. and D. Cass, "ISO transport services on top of
              the TCP: Version 3", STD 35, RFC 1006, May 1987.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1058]  Hedrick, C., "Routing Information Protocol", RFC 1058,
              June 1988.

   [RFC1112]  Deering, S., "Host extensions for IP multicasting", STD 5,
              RFC 1112, August 1989.

   [RFC1157]  Case, J., Fedor, M., Schoffstall, M., and J. Davin,



Baker & Meyer             Expires May 15, 2011                 [Page 38]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


              "Simple Network Management Protocol (SNMP)", STD 15,
              RFC 1157, May 1990.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, December 1990.

   [RFC1332]  McGregor, G., "The PPP Internet Protocol Control Protocol
              (IPCP)", RFC 1332, May 1992.

   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
              RFC 1661, July 1994.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC2046]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              November 1996.

   [RFC2047]  Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC2049]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Five: Conformance Criteria and
              Examples", RFC 2049, November 1996.

   [RFC2080]  Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
              January 1997.

   [RFC2126]  Pouffary, Y. and A. Young, "ISO Transport Service on top
              of TCP (ITOT)", RFC 2126, March 1997.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2357]  Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF



Baker & Meyer             Expires May 15, 2011                 [Page 39]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


              Criteria for Evaluating Reliable Multicast Transport and
              Application Protocols", RFC 2357, June 1998.

   [RFC2447]  Dawson, F., Mansour, S., and S. Silverberg, "iCalendar
              Message-Based Interoperability Protocol (iMIP)", RFC 2447,
              November 1998.

   [RFC2453]  Malkin, G., "RIP Version 2", STD 56, RFC 2453,
              November 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2464]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
              Networks", RFC 2464, December 1998.

   [RFC2474]  Nichols, K., Blake, S., Baker, F., and D. Black,
              "Definition of the Differentiated Services Field (DS
              Field) in the IPv4 and IPv6 Headers", RFC 2474,
              December 1998.

   [RFC2475]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
              and W. Weiss, "An Architecture for Differentiated
              Services", RFC 2475, December 1998.

   [RFC2516]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
              and R. Wheeler, "A Method for Transmitting PPP Over
              Ethernet (PPPoE)", RFC 2516, February 1999.

   [RFC2545]  Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
              Extensions for IPv6 Inter-Domain Routing", RFC 2545,
              March 1999.

   [RFC2588]  Finlayson, R., "IP Multicast and Firewalls", RFC 2588,
              May 1999.

   [RFC2608]  Guttman, E., Perkins, C., Veizades, J., and M. Day,
              "Service Location Protocol, Version 2", RFC 2608,
              June 1999.

   [RFC2615]  Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
              June 1999.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC2647]  Newman, D., "Benchmarking Terminology for Firewall



Baker & Meyer             Expires May 15, 2011                 [Page 40]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


              Performance", RFC 2647, August 1999.

   [RFC2663]  Srisuresh, P. and M. Holdrege, "IP Network Address
              Translator (NAT) Terminology and Considerations",
              RFC 2663, August 1999.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              October 1999.

   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
              March 2000.

   [RFC2979]  Freed, N., "Behavior of and Requirements for Internet
              Firewalls", RFC 2979, October 2000.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, November 2000.

   [RFC3022]  Srisuresh, P. and K. Egevang, "Traditional IP Network
              Address Translator (Traditional NAT)", RFC 3022,
              January 2001.

   [RFC3027]  Holdrege, M. and P. Srisuresh, "Protocol Complications
              with the IP Network Address Translator", RFC 3027,
              January 2001.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

   [RFC3032]  Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
              Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
              Encoding", RFC 3032, January 2001.

   [RFC3168]  Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
              of Explicit Congestion Notification (ECN) to IP",
              RFC 3168, September 2001.

   [RFC3235]  Senie, D., "Network Address Translator (NAT)-Friendly
              Application Design Guidelines", RFC 3235, January 2002.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3265]  Roach, A., "Session Initiation Protocol (SIP)-Specific



Baker & Meyer             Expires May 15, 2011                 [Page 41]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


              Event Notification", RFC 3265, June 2002.

   [RFC3275]  Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
              Language) XML-Signature Syntax and Processing", RFC 3275,
              March 2002.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.

   [RFC3376]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", RFC 3376, October 2002.

   [RFC3411]  Harrington, D., Presuhn, R., and B. Wijnen, "An
              Architecture for Describing Simple Network Management
              Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
              December 2002.

   [RFC3412]  Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
              "Message Processing and Dispatching for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3412,
              December 2002.

   [RFC3413]  Levi, D., Meyer, P., and B. Stewart, "Simple Network
              Management Protocol (SNMP) Applications", STD 62,
              RFC 3413, December 2002.

   [RFC3414]  Blumenthal, U. and B. Wijnen, "User-based Security Model
              (USM) for version 3 of the Simple Network Management
              Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.

   [RFC3415]  Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
              Access Control Model (VACM) for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3415,
              December 2002.

   [RFC3416]  Presuhn, R., "Version 2 of the Protocol Operations for the
              Simple Network Management Protocol (SNMP)", STD 62,
              RFC 3416, December 2002.

   [RFC3417]  Presuhn, R., "Transport Mappings for the Simple Network
              Management Protocol (SNMP)", STD 62, RFC 3417,
              December 2002.

   [RFC3418]  Presuhn, R., "Management Information Base (MIB) for the
              Simple Network Management Protocol (SNMP)", STD 62,
              RFC 3418, December 2002.



Baker & Meyer             Expires May 15, 2011                 [Page 42]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
              Self-Address Fixing (UNSAF) Across Network Address
              Translation", RFC 3424, November 2002.

   [RFC3436]  Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
              Layer Security over Stream Control Transmission Protocol",
              RFC 3436, December 2002.

   [RFC3453]  Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,
              M., and J. Crowcroft, "The Use of Forward Error Correction
              (FEC) in Reliable Multicast", RFC 3453, December 2002.

   [RFC3511]  Hickman, B., Newman, D., Tadjudin, S., and T. Martin,
              "Benchmarking Methodology for Firewall Performance",
              RFC 3511, April 2003.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3561]  Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
              Demand Distance Vector (AODV) Routing", RFC 3561,
              July 2003.

   [RFC3569]  Bhattacharyya, S., "An Overview of Source-Specific
              Multicast (SSM)", RFC 3569, July 2003.

   [RFC3590]  Haberman, B., "Source Address Selection for the Multicast
              Listener Discovery (MLD) Protocol", RFC 3590,
              September 2003.

   [RFC3626]  Clausen, T. and P. Jacquet, "Optimized Link State Routing
              Protocol (OLSR)", RFC 3626, October 2003.

   [RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation
              (NAT) Compatibility Requirements", RFC 3715, March 2004.

   [RFC3810]  Vida, R. and L. Costa, "Multicast Listener Discovery
              Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

   [RFC3828]  Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
              G. Fairhurst, "The Lightweight User Datagram Protocol
              (UDP-Lite)", RFC 3828, July 2004.

   [RFC3853]  Peterson, J., "S/MIME Advanced Encryption Standard (AES)
              Requirement for the Session Initiation Protocol (SIP)",
              RFC 3853, July 2004.




Baker & Meyer             Expires May 15, 2011                 [Page 43]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   [RFC3971]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
              Neighbor Discovery (SEND)", RFC 3971, March 2005.

   [RFC3973]  Adams, A., Nicholas, J., and W. Siadak, "Protocol
              Independent Multicast - Dense Mode (PIM-DM): Protocol
              Specification (Revised)", RFC 3973, January 2005.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, March 2005.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, March 2005.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005.

   [RFC4262]  Santesson, S., "X.509 Certificate Extension for Secure/
              Multipurpose Internet Mail Extensions (S/MIME)
              Capabilities", RFC 4262, December 2005.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

   [RFC4289]  Freed, N. and J. Klensin, "Multipurpose Internet Mail
              Extensions (MIME) Part Four: Registration Procedures",
              BCP 13, RFC 4289, December 2005.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, February 2006.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the
              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
              December 2005.



Baker & Meyer             Expires May 15, 2011                 [Page 44]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   [RFC4309]  Housley, R., "Using Advanced Encryption Standard (AES) CCM
              Mode with IPsec Encapsulating Security Payload (ESP)",
              RFC 4309, December 2005.

   [RFC4320]  Sparks, R., "Actions Addressing Identified Issues with the
              Session Initiation Protocol's (SIP) Non-INVITE
              Transaction", RFC 4320, January 2006.

   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.

   [RFC4347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
              Security", RFC 4347, April 2006.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, February 2006.

   [RFC4410]  Pullen, M., Zhao, F., and D. Cohen, "Selectively Reliable
              Multicast Protocol (SRMP)", RFC 4410, February 2006.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC4487]  Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile
              IPv6 and Firewalls: Problem Statement", RFC 4487,
              May 2006.

   [RFC4492]  Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
              Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
              for Transport Layer Security (TLS)", RFC 4492, May 2006.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC4594]  Babiarz, J., Chan, K., and F. Baker, "Configuration
              Guidelines for DiffServ Service Classes", RFC 4594,
              August 2006.

   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
              Protocol Specification (Revised)", RFC 4601, August 2006.

   [RFC4604]  Holbrook, H., Cain, B., and B. Haberman, "Using Internet
              Group Management Protocol Version 3 (IGMPv3) and Multicast
              Listener Discovery Protocol Version 2 (MLDv2) for Source-
              Specific Multicast", RFC 4604, August 2006.




Baker & Meyer             Expires May 15, 2011                 [Page 45]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   [RFC4607]  Holbrook, H. and B. Cain, "Source-Specific Multicast for
              IP", RFC 4607, August 2006.

   [RFC4608]  Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific
              Protocol Independent Multicast in 232/8", BCP 120,
              RFC 4608, August 2006.

   [RFC4614]  Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
              for Transmission Control Protocol (TCP) Specification
              Documents", RFC 4614, September 2006.

   [RFC4741]  Enns, R., "NETCONF Configuration Protocol", RFC 4741,
              December 2006.

   [RFC4742]  Wasserman, M. and T. Goddard, "Using the NETCONF
              Configuration Protocol over Secure SHell (SSH)", RFC 4742,
              December 2006.

   [RFC4743]  Goddard, T., "Using NETCONF over the Simple Object Access
              Protocol (SOAP)", RFC 4743, December 2006.

   [RFC4744]  Lear, E. and K. Crozier, "Using the NETCONF Protocol over
              the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744,
              December 2006.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              January 2007.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC4835]  Manral, V., "Cryptographic Algorithm Implementation
              Requirements for Encapsulating Security Payload (ESP) and
              Authentication Header (AH)", RFC 4835, April 2007.

   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
              September 2007.

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862, September 2007.

   [RFC4916]  Elwell, J., "Connected Identity in the Session Initiation
              Protocol (SIP)", RFC 4916, June 2007.

   [RFC4919]  Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6



Baker & Meyer             Expires May 15, 2011                 [Page 46]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals",
              RFC 4919, August 2007.

   [RFC4941]  Narten, T., Draves, R., and S. Krishnan, "Privacy
              Extensions for Stateless Address Autoconfiguration in
              IPv6", RFC 4941, September 2007.

   [RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
              "Transmission of IPv6 Packets over IEEE 802.15.4
              Networks", RFC 4944, September 2007.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol",
              RFC 4960, September 2007.

   [RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common
              Mitigations", RFC 4987, August 2007.

   [RFC5023]  Gregorio, J. and B. de hOra, "The Atom Publishing
              Protocol", RFC 5023, October 2007.

   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
              Kozuka, "Stream Control Transmission Protocol (SCTP)
              Dynamic Address Reconfiguration", RFC 5061,
              September 2007.

   [RFC5072]  S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
              PPP", RFC 5072, September 2007.

   [RFC5128]  Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
              Peer (P2P) Communication across Network Address
              Translators (NATs)", RFC 5128, March 2008.

   [RFC5135]  Wing, D. and T. Eckert, "IP Multicast Requirements for a
              Network Address Translator (NAT) and a Network Address
              Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.

   [RFC5193]  Jayaraman, P., Lopez, R., Ohba, Y., Parthasarathy, M., and
              A. Yegin, "Protocol for Carrying Authentication for
              Network Access (PANA) Framework", RFC 5193, May 2008.

   [RFC5207]  Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
              Firewall Traversal Issues of Host Identity Protocol (HIP)
              Communication", RFC 5207, April 2008.

   [RFC5216]  Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
              Authentication Protocol", RFC 5216, March 2008.




Baker & Meyer             Expires May 15, 2011                 [Page 47]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   [RFC5238]  Phelan, T., "Datagram Transport Layer Security (DTLS) over
              the Datagram Congestion Control Protocol (DCCP)",
              RFC 5238, May 2008.

   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246, August 2008.

   [RFC5277]  Chisholm, S. and H. Trevino, "NETCONF Event
              Notifications", RFC 5277, July 2008.

   [RFC5289]  Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
              256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
              August 2008.

   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
              October 2008.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, July 2008.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC5393]  Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen,
              "Addressing an Amplification Vulnerability in Session
              Initiation Protocol (SIP) Forking Proxies", RFC 5393,
              December 2008.

   [RFC5405]  Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
              for Application Designers", BCP 145, RFC 5405,
              November 2008.

   [RFC5430]  Salter, M., Rescorla, E., and R. Housley, "Suite B Profile
              for Transport Layer Security (TLS)", RFC 5430, March 2009.

   [RFC5539]  Badra, M., "NETCONF over Transport Layer Security (TLS)",
              RFC 5539, May 2009.

   [RFC5545]  Desruisseaux, B., "Internet Calendaring and Scheduling
              Core Object Specification (iCalendar)", RFC 5545,
              September 2009.

   [RFC5546]  Daboo, C., "iCalendar Transport-Independent
              Interoperability Protocol (iTIP)", RFC 5546,
              December 2009.

   [RFC5548]  Dohler, M., Watteyne, T., Winter, T., and D. Barthel,



Baker & Meyer             Expires May 15, 2011                 [Page 48]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


              "Routing Requirements for Urban Low-Power and Lossy
              Networks", RFC 5548, May 2009.

   [RFC5569]  Despres, R., "IPv6 Rapid Deployment on IPv4
              Infrastructures (6rd)", RFC 5569, January 2010.

   [RFC5621]  Camarillo, G., "Message Body Handling in the Session
              Initiation Protocol (SIP)", RFC 5621, September 2009.

   [RFC5673]  Pister, K., Thubert, P., Dwars, S., and T. Phinney,
              "Industrial Routing Requirements in Low-Power and Lossy
              Networks", RFC 5673, October 2009.

   [RFC5681]  Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
              Control", RFC 5681, September 2009.

   [RFC5717]  Lengyel, B. and M. Bjorklund, "Partial Lock Remote
              Procedure Call (RPC) for NETCONF", RFC 5717,
              December 2009.

   [RFC5740]  Adamson, B., Bormann, C., Handley, M., and J. Macker,
              "NACK-Oriented Reliable Multicast (NORM) Transport
              Protocol", RFC 5740, November 2009.

   [RFC5750]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Certificate
              Handling", RFC 5750, January 2010.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

   [RFC5785]  Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
              Uniform Resource Identifiers (URIs)", RFC 5785,
              April 2010.

   [RFC5826]  Brandt, A., Buron, J., and G. Porcu, "Home Automation
              Routing Requirements in Low-Power and Lossy Networks",
              RFC 5826, April 2010.

   [RFC5838]  Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
              Aggarwal, "Support of Address Families in OSPFv3",
              RFC 5838, April 2010.

   [RFC5867]  Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
              "Building Automation Routing Requirements in Low-Power and
              Lossy Networks", RFC 5867, June 2010.




Baker & Meyer             Expires May 15, 2011                 [Page 49]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
              Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

   [RFC5932]  Kato, A., Kanda, M., and S. Kanno, "Camellia Cipher Suites
              for TLS", RFC 5932, June 2010.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              October 2010.

   [SP-MULPIv3.0]
              CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols
              Interface Specification, CM-SP-MULPIv3.0-I10-090529",
              May 2009.


Appendix A.  Example: Advanced Metering Infrastructure

   This appendix provides a worked example of the use of the Internet
   Protocol Suite in a network such as the Smart Grid's Advanced
   Metering Infrastructure (AMI).  There are several possible models.

   Figure 6 shows the structure of the AMI as it reaches out towards a
   set of residences.  In this structure, we have the home itself and
   its Home Area Network (HAN), the Neighborhood Area Network (NAN) that
   the utility uses to access the meter at the home, and the utility
   access network that connects a set of NANs to the utility itself.
   For the purposes of this discussion, assume that the NAN contains a
   distributed application in a set collectors, which is of course only
   one way the application could be implemented.
















Baker & Meyer             Expires May 15, 2011                 [Page 50]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


    ---
    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                +---------+
    ---

       Figure 6: The HAN, NAN, and Utility in the Advanced Metering
                              Infrastructure

   There are several questions that have to be answered in describing
   this picture, which given possible answers yield different possible
   models.  They include at least:

   o  How does Demand Response work?  Either:

      *  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.

   o  How does the utility access meters at the home?

      *  The AMI Headend manages the interfaces with the meters,
         collecting metering data and passing it on to the appropriate
         applications over the Enterprise Bus, or





Baker & Meyer             Expires May 15, 2011                 [Page 51]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


      *  Distributed application support (collectors") might access and
         summarize the information; this device might be managed by the
         utility or by a service between the utility and its customers.

   In implementation, these models are idealized; reality may include
   some aspects of each model in specified cases.

   The examples include:

   1.  Appendix A.2 presumes that the HAN, the NAN, and the utility's
       network are separate administrative domains and speak application
       to application across those domains.

   2.  Appendix A.3 repeats the first example, but presuming that the
       utility directly accesses appliances within the HAN from the
       collector".

   3.  Appendix A.4 repeats the first example, but presuming that the
       collector directly forwards traffic as a router in addition to
       distributed application chores.  Note that this case implies
       numerous privacy and security concerns and as such is considered
       a less likely deployment model.

A.1.  How to structure a network

   A key consideration in the Internet has been the development of new
   link layer technologies over time.  The ARPANET originally used a BBN
   proprietary link layer called BBN 1822 [1822].  In the late 1970's,
   the ARPANET switched to X.25 as an interface to the 1822 network.
   With the deployment of the IEEE 802 series technologies in the early
   1980's, IP was deployed on Ethernet (IEEE 802.3), Token Ring (IEEE
   802.5) and WiFi (IEEE 802.11), as well as Arcnet, serial lines of
   various kinds, Frame Relay, and ATM.  A key issue in this evolution
   was that the applications developed to run on the Internet use APIs
   related to the IPS, and as a result require little or no change to
   continue to operate in a new link layer architecture or a mixture of
   them.

   The Smart Grid is likely to see a similar evolution over time.
   Consider the Home Area Network (HAN) as a readily understandable
   small network.  At this juncture, technologies proposed for
   residential networks include IEEE P1901, various versions of IEEE
   802.15.4, and IEEE 802.11.  It is reasonable to expect other
   technologies to be developed in the future.  As the Zigbee Alliance
   has learned (and as a resulted incorporated the IPS in Smart Energy
   Profile 2.0), there is significant value in providing a virtual
   address that is mapped to interfaces or nodes attached to each of
   those technologies.



Baker & Meyer             Expires May 15, 2011                 [Page 52]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


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


               A        thermostats, appliances, etc
               |  ------+----------------+------------------
               |"HAN"   |                |
               |    +---+---+        +---+---+
               |    |Router |        | Meter |
               |    |or EMS |        |       |
               V    +---+---+        +---+---+
               ---      |       ---      \
                        |       ^         \   |   /
                        |       |"NAN"     \  |  /
                     ---+---    |        +--+-+-+---+
                    /       \   |        |"Pole Top"|
                   | Internet|  v        +----+-----+
                    \       /   ---
                     -------

                Figure 7: Two views of a Home Area Network

   There are two possible communication models within the HAN, both of
   which are likely to be useful.  Devices may communicate directly with
   each other, or they may be managed by some central controller.  An
   example of direct communications might be a light switch that
   directly commands a lamp to turn on or off.  An example of indirect
   communications might be a control application in a Customer or
   Building that accepts telemetry from a thermostat, applies some form
   of policy, and controls the heating and air conditioning systems.  In
   addition, there are high end appliances in the market today that use
   residential broadband to communicate with their manufacturers, and



Baker & Meyer             Expires May 15, 2011                 [Page 53]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   obviously the meter needs to communicate with the utility.

   Figure 7 shows two simple networks, one of which IEEE 802.15.4 and
   IEEE 1901 domains, and one of which uses an arbitrary LAN within the
   home, which could be IEEE 802.3/Ethernet, IEEE 802.15.4, IEEE 1901,
   IEEE 802.11, or anything else that made sense in context.  Both show
   the connectivity between them as a router separate from the EMS.
   This is for clarity; the two could of course be incorporated into a
   single system, and one could imagine appliances that want to
   communicate with their manufacturers supporting both a HAN interface
   and a WiFi interface rather than depending on the router.  These are
   all manufacturer design decisions.

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
   [RFC3315]).  In addition, the HAN will have link-local addresses that
   can be used between neighboring nodes.  In general, an HAN will be
   comprised of both 802.15.4, 802.11 (and possibly other) networks.

   The ESI is a node on the user's residential network, and will not
   typically provide stateful packet forwarding or firewall services
   between the HAN and the utility network(s).  In general, the ESI is a
   node on the home network; in some cases, the meter may act as the
   ESI.  However, the ESI must be capable of understanding that most
   home networks are not 802.15.4 enabled (rather, they are typically
   802.11 networks), and that it must be capable of setting up ad-hoc
   networks between various sensors in the home (e.g., 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



Baker & Meyer             Expires May 15, 2011                 [Page 54]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


      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.



Baker & Meyer             Expires May 15, 2011                 [Page 55]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


A.2.  Model 1: AMI with separated domains

   With the background given in Appendix A.1, we can now discuss the use
   of IP (IPv4 or IPv6) in the AMI.

   In this first model, consider the three domains in Figure 6 to
   literally be separate administrative domains, potentially operated by
   different entities.  For example, the NAN could be a WiMAX network
   operated by a traditional telecom operator, the utility's network
   (including the collector) is its own, and the residential network is
   operated by the resident.  In this model, while communications
   between the collector and the Meter are normal, the utility has no
   other access to appliances in the home, and the collector doesn't
   directly forward messages from the NAN upstream.

   In this case, as shown in Figure 7, it would make the most sense to
   design the collector, the Meter, and the EMS as hosts on the NAN -
   design them as systems whose applications can originate and terminate
   exchanges or sessions in the NAN, but not forward traffic from or to
   other devices.

   In such a configuration, Demand Response has to be performed by
   having the EMS accept messages such as price signals from the "pole
   top", apply some form of policy, and then orchestrate actions within
   the home.  Another possibility is to have the EMS communicate with
   the ESI located in the meter.  If the thermostat has high demand and
   low demand (day/night or morning/day/evening/night) settings, Demand
   Response might result in it moving to a lower demand setting, and the
   EMS might also turn off specified circuits in the home to diminish
   lighting.

   In this scenario, Quality of Service (QoS) issues reportedly arise
   when high precedence messages must be sent through the collector to
   the home; if the collector is occupied polling the meters or doing
   some other task, the application may not yield control of the
   processor to the application that services the message.  Clearly,
   this is either an application or an Operating System problem;
   applications need to be designed in a manner that doesn't block high
   precedence messages.  The collector also needs to use appropriate NAN
   services, if they exist, to provide the NAN QoS it needs.  For
   example, if WiMax is in use, it might use a routine-level service for
   normal exchanges but a higher precedence service for these messages.

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



Baker & Meyer             Expires May 15, 2011                 [Page 56]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   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|
                             +--+ +--+ +--+

                        Figure 8: Home Area Network

   In this case, as shown in Figure 8, the Meter, and EMS as hosts on
   the HAN, and there is a router between the HAN and the NAN.

   As one might imagine, there are serious security considerations in
   this model.  Traffic between the NAN and the residential broadband
   network should be filtered, and the issues raised in Appendix A.1.2
   take on a new level of meaning.  One of the biggest threats may be a
   legal or at least a public relations issue; if the utility
   intentionally disables a circuit in a manner or at a time that
   threatens life (the resident's kidney dialysis machine is on it, or a
   respirator, for example) the matter might make the papers.
   Unauthorized access could be part of juvenile pranks or other things
   as well.  So one really wants the appliances to only obey commands
   under strict authentication/authorization controls.

   In addition to the QoS issues raised in Appendix A.2, there is the
   possibility of queuing issues in the router.  In such a case, the IP
   datagrams should probably use the Low-Latency Data Service Class
   described in [RFC4594], and let other traffic use the Standard
   Service Class or other service classes.

A.4.  Model 3: Collector is an IP router

   In this third model, the relationship between the NAN and the HAN is
   either as in Appendix A.2 or Appendix A.3; what is different is that



Baker & Meyer             Expires May 15, 2011                 [Page 57]


Internet-Draft    Internet Protocols for the Smart Grid    November 2010


   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, there are serious security
   considerations in this model.  Traffic being forwarded should be
   filtered, and the issues raised in Appendix A.1.2 take on a new level
   of meaning - but this time at the utility mainframe.  Unauthorized
   access is likely similar to other financially-motivated attacks that
   happen in the Internet, but presumably would be coming from devices
   in the HAN that have been co-opted in some way.  One really wants the
   appliances to only obey commands under strict authentication/
   authorization controls.

   In addition to the QoS issues raised in Appendix A.2, there is the
   possibility of queuing issues in the collector.  In such a case, the
   IP datagrams should probably use the Low-Latency Data Service Class
   described in [RFC4594], and let other traffic use the Standard
   Service Class or other service classes.


Authors' Addresses

   Fred Baker
   Cisco Systems
   Santa Barbara, California  93117
   USA

   Email: fred@cisco.com


   David Meyer
   Cisco Systems
   Eugene, Oregon  97403
   USA

   Email: dmm@cisco.com














Baker & Meyer             Expires May 15, 2011                 [Page 58]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/