[smartpowerdir] Diff: draft-baker-ietf-core-07.txt - sg-ietf-compendium.txt
Fred Baker <fred@cisco.com> Mon, 25 October 2010 18:46 UTC
Return-Path: <fred@cisco.com>
X-Original-To: smartpowerdir@core3.amsl.com
Delivered-To: smartpowerdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 800FA3A697F for <smartpowerdir@core3.amsl.com>; Mon, 25 Oct 2010 11:46:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RRJf-S6cqm3D for <smartpowerdir@core3.amsl.com>; Mon, 25 Oct 2010 11:46:02 -0700 (PDT)
Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 61DB03A682F for <smartpowerdir@ietf.org>; Mon, 25 Oct 2010 11:45:59 -0700 (PDT)
Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos; i="4.58,236,1286150400"; d="scan'208,217"; a="374355716"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 25 Oct 2010 18:47:44 +0000
Received: from stealth-10-32-244-222.cisco.com (stealth-10-32-244-222.cisco.com [10.32.244.222]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o9PIlNeN019476 for <smartpowerdir@ietf.org>; Mon, 25 Oct 2010 18:47:25 GMT
Received: from [127.0.0.1] by stealth-10-32-244-222.cisco.com (PGP Universal service); Mon, 25 Oct 2010 11:47:30 -0700
X-PGP-Universal: processed; by stealth-10-32-244-222.cisco.com on Mon, 25 Oct 2010 11:47:30 -0700
From: Fred Baker <fred@cisco.com>
Date: Mon, 25 Oct 2010 11:47:16 -0700
Message-Id: <1144520E-FC10-4A67-AE2D-95584E1A9D8D@cisco.com>
To: IETF SmartPower Directorate <smartpowerdir@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1081)
X-Mailer: Apple Mail (2.1081)
Content-Type: multipart/alternative; boundary="Apple-Mail-46-487591200"
Subject: [smartpowerdir] Diff: draft-baker-ietf-core-07.txt - sg-ietf-compendium.txt
X-BeenThere: smartpowerdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Members of the Smart Power Directorate <smartpowerdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/smartpowerdir>
List-Post: <mailto:smartpowerdir@ietf.org>
List-Help: <mailto:smartpowerdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/smartpowerdir>, <mailto:smartpowerdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Oct 2010 18:46:03 -0000
On Oct 25, 2010, at 11:29 AM, IETF I-D Submission Tool wrote: > > A new version of I-D, draft-baker-ietf-core-09.txt has been successfully submitted by Fred Baker and posted to the IETF repository. > > Filename: draft-baker-ietf-core > Revision: 09 > Title: Internet Protocols for the Smart Grid > Creation_date: 2010-10-25 > WG ID: Independent Submission > Number_of_pages: 57 > > 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. < draft-baker-ietf-core-07.txt sg-ietf-compendium.txt Network Working Group F. Baker Network Working Group F. Baker Internet-Draft D. Meyer Internet-Draft D. Meyer Intended status: Informational Cisco Systems Intended status: Informational Cisco Systems Expires: February 18, 2011 August 17, 2010 Expires: April 28, 2011 October 25, 2010 Internet Protocols for the Smart Grid Internet Protocols for the Smart Grid draft-baker-ietf-core-07 draft-baker-ietf-core-09 Abstract Abstract This note identifies the key protocols of the Internet Protocol Suite This note identifies the key protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In practice, such a profile would Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from consist of selecting what is needed for Smart Grid deployment from the picture presented here. the picture presented here. skipping to change at page 1, line 35 skipping to change at page 1, line 35 Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." material or to cite them other than as "work in progress." This Internet-Draft will expire on February 18, 2011. This Internet-Draft will expire on April 28, 2011. Copyright Notice Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents publication of this document. Please review these documents skipping to change at page 2, line 19 skipping to change at page 2, line 19 2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 5 2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 5 2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 5 2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 5 2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 6 2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 7 2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . 8 2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . 8 2.1.3.2. Lower layer networks . . . . . . . . . . . . . . . 8 2.1.3.2. Lower layer networks . . . . . . . . . . . . . . . 8 2.1.4. Media layers: Physical and Link . . . . . . . . . . . 8 2.1.4. Media layers: Physical and Link . . . . . . . . . . . 8 2.2. Security issues . . . . . . . . . . . . . . . . . . . . . 8 2.2. Security issues . . . . . . . . . . . . . . . . . . . . . 8 2.2.1. Physical security . . . . . . . . . . . . . . . . . . 9 2.2.1. Physical security . . . . . . . . . . . . . . . . . . 9 2.2.2. Session identification . . . . . . . . . . . . . . . . 9 2.2.2. Session Authentication . . . . . . . . . . . . . . . . 9 2.2.3. Confidentiality . . . . . . . . . . . . . . . . . . . 10 2.2.3. Confidentiality . . . . . . . . . . . . . . . . . . . 10 2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 11 2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 11 2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 11 2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 11 2.3.2. Network Management . . . . . . . . . . . . . . . . . . 11 2.3.2. Network Management . . . . . . . . . . . . . . . . . . 11 3. Specific protocols . . . . . . . . . . . . . . . . . . . . . . 11 3. Specific protocols . . . . . . . . . . . . . . . . . . . . . . 11 3.1. Security solutions . . . . . . . . . . . . . . . . . . . . 12 3.1. Security solutions . . . . . . . . . . . . . . . . . . . . 12 3.1.1. Session identification, authentication, 3.1.1. Session identification, authentication, authorization, and accounting . . . . . . . . . . . . 12 authorization, and accounting . . . . . . . . . . . . 12 3.1.2. IP Security Architecture (IPsec) . . . . . . . . . . . 12 3.1.2. IP Security Architecture (IPsec) . . . . . . . . . . . 12 3.1.3. Transport Layer Security (TLS) . . . . . . . . . . . . 12 3.1.3. Transport Layer Security (TLS) . . . . . . . . . . . . 13 3.1.4. Secure/Multipurpose Internet Mail Extensions 3.1.4. Secure/Multipurpose Internet Mail Extensions (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 13 (S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 13 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 14 3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 13 3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 14 3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . . . . 14 3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . . . . 14 3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . 14 3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . 15 3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . 14 3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . 15 3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . 15 3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . 16 3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . 16 3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . 17 3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 16 3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 17 3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . 16 3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . 17 3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . 17 3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . 18 3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . 17 3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . 18 3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 18 3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 19 3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . 18 3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . 19 3.2.4.1. Routing Information Protocol . . . . . . . . . . . 18 3.2.4.1. Routing Information Protocol . . . . . . . . . . . 19 3.2.4.2. Open Shortest Path First . . . . . . . . . . . . . 19 3.2.4.2. Open Shortest Path First . . . . . . . . . . . . . 19 3.2.4.3. ISO Intermediate System to Intermediate System . . 19 3.2.4.3. ISO Intermediate System to Intermediate System . . 20 3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . 19 3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . 20 3.2.4.5. Dynamic MANET On-demand (DYMO) Routing . . . . . . 20 3.2.4.5. Dynamic MANET On-demand (DYMO) Routing . . . . . . 20 3.2.4.6. Optimized Link State Routing Protocol . . . . . . 20 3.2.4.6. Optimized Link State Routing Protocol . . . . . . 21 3.2.4.7. Routing for Low power and Lossy Networks . . . . . 20 3.2.4.7. Routing for Low power and Lossy Networks . . . . . 21 3.2.5. IPv6 Multicast Forwarding and Routing . . . . . . . . 20 3.2.5. IPv6 Multicast Forwarding and Routing . . . . . . . . 22 3.2.5.1. Protocol-Independent Multicast Routing . . . . . . 21 3.2.5.1. Protocol-Independent Multicast Routing . . . . . . 22 3.2.6. Adaptation to lower layer networks and link layer 3.2.6. Adaptation to lower layer networks and link layer protocols . . . . . . . . . . . . . . . . . . . . . . 21 protocols . . . . . . . . . . . . . . . . . . . . . . 23 3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 22 3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 23 3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 22 3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 23 3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 22 3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 24 3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 23 3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 24 3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 23 3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 25 3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 24 3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 25 3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 24 3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 25 3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 24 3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 26 3.5. Service and Resource Discovery . . . . . . . . . . . . . . 24 3.4.3. Network Time . . . . . . . . . . . . . . . . . . . . . 26 3.5.1. Service Discovery . . . . . . . . . . . . . . . . . . 24 3.5. Network Management . . . . . . . . . . . . . . . . . . . . 26 3.5.2. Resource Discovery . . . . . . . . . . . . . . . . 25 3.5.1. Simple Network Management Protocol (SNMP) . . . . . . 26 3.6. Other Applications . . . . . . . . . . . . . . . . . . . . 26 3.5.2. Network Configuration (NETCONF) Protocol . . . . . . . 27 3.6.1. Network Time . . . . . . . . . . . . . . . . . . . . . 26 3.6. Service and Resource Discovery . . . . . . . . . . . . . . 28 3.6.2. Session Initiation Protocol . . . . . . . . . . . . . 26 3.6.1. Service Discovery . . . . . . . . . . . . . . . . . . 28 3.6.3. Calendaring . . . . . . . . . . . . . . . . . . . . . 27 3.6.2. Resource Discovery . . . . . . . . . . . . . . . . . . 28 4. A simplified view of the business architecture . . . . . . . . 27 3.7. Other Applications . . . . . . . . . . . . . . . . . . . . 29 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 3.7.1. Session Initiation Protocol . . . . . . . . . . . . . 29 6. Security Considerations . . . . . . . . . . . . . . . . . . . 32 3.7.2. Calendaring . . . . . . . . . . . . . . . . . . . . . 30 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 4. A simplified view of the business architecture . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8.1. Normative References . . . . . . . . . . . . . . . . . . . 32 6. Security Considerations . . . . . . . . . . . . . . . . . . . 35 8.2. Informative References . . . . . . . . . . . . . . . . . . 32 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 8.1. Normative References . . . . . . . . . . . . . . . . . . . 35 8.2. Informative References . . . . . . . . . . . . . . . . . . 35 Appendix A. Example: Advanced Metering Infrastructure . . . . . . 49 A.1. How to structure a network . . . . . . . . . . . . . . . . 51 A.1.1. HAN Routing . . . . . . . . . . . . . . . . . . . . . 53 A.1.2. HAN Security . . . . . . . . . . . . . . . . . . . . . 53 A.2. Model 1: AMI with separated domains . . . . . . . . . . . 54 A.3. Model 2: AMI with neighborhood access to the home . . . . 55 A.4. Model 3: Collector is an IP router . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57 1. Introduction 1. Introduction This document provides Smart Grid designers with advice on how to This document provides Smart Grid designers with advice on how to best "profile" the Internet Protocol Suite (IPS) for use on with best "profile" the Internet Protocol Suite (IPS) for use on with Smart Grids. It provides an overview of the IPS and the key Smart Grids. It provides an overview of the IPS and the key protocols that are critical in integrating Smart Grid devices into an protocols that are critical in integrating Smart Grid devices into an IP-based infrastructure. IP-based infrastructure. The IPS provides options for several key architectural components. The IPS provides options for several key architectural components. skipping to change at page 4, line 45 skipping to change at page 4, line 45 o IPv6 Node Requirements [RFC4294], o IPv6 Node Requirements [RFC4294], At this writing, RFC 4294 is in the process of being updated, in At this writing, RFC 4294 is in the process of being updated, in [I-D.ietf-6man-node-req-bis]. [I-D.ietf-6man-node-req-bis]. This document is intended to provide Smart Grid architects and This document is intended to provide Smart Grid architects and designers with a compendium of relevant RFCs (and to some extent designers with a compendium of relevant RFCs (and to some extent Internet Drafts), and is organized as an annotated list of RFCs. To Internet Drafts), and is organized as an annotated list of RFCs. To that end, the remainder of this document is organized as follows: that end, the remainder of this document is organized as follows: Section 2 describes the Internet Architecture and its protocol suite. Section 3 outlines the set of protocols that will be useful in Smart o Section 2 describes the Internet Architecture and its protocol Grid deployment. Finally, Section 4 provides an overview of the suite. business architecture embodied in the design and deployment of the IPS. o Section 3 outlines the set of protocols that will be useful in Smart Grid deployment. 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 2. The Internet Protocol Suite Before enumerating the list of Internet protocols relevant to Smart Before enumerating the list of Internet protocols relevant to Smart Grid, we discuss the layered architecture of the IPS, the functions Grid, we discuss the layered architecture of the IPS, the functions of the various layers, and their associated protocols. of the various layers, and their associated protocols. 2.1. Internet Protocol Layers 2.1. Internet Protocol Layers While Internet architecture uses the definitions and language similar While Internet architecture uses the definitions and language similar skipping to change at page 8, line 49 skipping to change at page 8, line 49 At the lowest layer of the IP architecture, data is encoded in At the lowest layer of the IP architecture, data is encoded in messages and transmitted over the physical media. While the IETF messages and transmitted over the physical media. While the IETF specifies algorithms for carrying IPv4 and IPv6 various media types, specifies algorithms for carrying IPv4 and IPv6 various media types, it rarely actually defines the media - it happily uses specifications it rarely actually defines the media - it happily uses specifications from IEEE, ITU, and other sources. from IEEE, ITU, and other sources. 2.2. Security issues 2.2. Security issues While it is popular to complain about the security of the Internet, While it is popular to complain about the security of the Internet, solutions to many Internet security problems already exist but have solutions to many Internet security problems already exist but have not been widely deployed. Internet security solutions attempt to either not been widely deployed, may impact critical performance mitigate a set of known threats at a specified cost; addressing criteria, or require security measures outside the IPS. Internet security issues requires first a threat analysis and assessment and a security solutions attempt to mitigate a set of known threats within set of mitigations appropriate to the threats. Since we have threats the IPS domain at a specified cost; addressing security issues at every layer, we should expect to find mitigations at every layer. 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 2.2.1. Physical security At the physical and data link layers, threats generally center on At the physical and data link layers, threats generally center on physical attacks on the network - the effects of backhoes, physical attacks on the network - the effects of backhoes, deterioration of physical media, and various kinds of environmental deterioration of physical media, and various kinds of environmental noise. Radio-based networks are subject to signal fade due to noise. Radio-based networks are subject to signal fade due to distance, interference, and environmental factors; it is widely noted distance, interference, and environmental factors; it is widely noted that IEEE 802.15.4 networks frequently place a metal ground plate 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 between the meter and the device that manages it. Fiber was at one skipping to change at page 9, line 26 skipping to change at page 9, line 28 learned to tap it by bending the fiber and collecting incidental learned to tap it by bending the fiber and collecting incidental light, and we have learned about backhoes. As a result, some light, and we have learned about backhoes. As a result, some installations encase fiber optic cable in a pressurized sheath, both installations encase fiber optic cable in a pressurized sheath, both to quickly identify the location of a cut and to make it more to quickly identify the location of a cut and to make it more difficult to tap. difficult to tap. While there are protocol behaviors that can detect certain classes of While there are protocol behaviors that can detect certain classes of physical faults, such as keep-alive exchanges, physical security is physical faults, such as keep-alive exchanges, physical security is generally not considered to be a protocol problem. generally not considered to be a protocol problem. 2.2.2. Session identification 2.2.2. Session Authentication At the transport and application layers and in lower layer networks At the transport and application layers and in lower layer networks where dynamic connectivity such as ATM Switched Virtual Circuits where dynamic connectivity such as ATM Switched Virtual Circuits (SVCs) or "dial" connectivity are in use, there tend to be several (SVCs) or "dial" connectivity are in use, there tend to be several different classes of authentication/authorization requirements. The different classes of authentication/authorization requirements. The basic requirements that must be satisfied are: basic requirements that must be satisfied are: 1. Verify that peers are appropriate partners; this generally means 1. Verify that peers are appropriate partners; this generally means knowing "who" they are and that they have a "need to know" or are knowing "who" they are and that they have a "need to know" or are trusted sources. trusted sources. skipping to change at page 10, line 9 skipping to change at page 10, line 11 against modification attacks. against modification attacks. In other words, both the communications channel itself and message In other words, both the communications channel itself and message exchanges (both by knowing the source of the information and to have exchanges (both by knowing the source of the information and to have proof of its validity) must be secured. Three examples suffice to proof of its validity) must be secured. Three examples suffice to illustrate the challenges. illustrate the challenges. One common attack against a TCP session is to bombard the session One common attack against a TCP session is to bombard the session with reset messages. Other attacks against TCP include the "SYN with reset messages. Other attacks against TCP include the "SYN flooding" attack, in which an attacker attempts to exhaust the memory flooding" attack, in which an attacker attempts to exhaust the memory of the target by creating TCP state. Experience has shown that by of the target by creating TCP state. In particular, the attacker including information in the transport header or a related protocol attempts to exhaust the target's memory by opening a large number of like the IPsec (Section 3.1.2) or TLS (Section 3.1.3), a host can unique TCP connections, each of which is represented by a identify legitimate messages and discard mitigate any damage that may Transmission Control Block (TCB). The attack is successful if the have been caused by the attack. 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 Another common attack involves unauthorized communication with a router or a service. For example, an unauthorized party might try to router or a service. For example, an unauthorized party might try to join the routing system. To protect against such attacks, an join the routing system. To protect against such attacks, an Internet Service Provider (ISP) should not accept information from Internet Service Provider (ISP) should not accept information from new peers without verifying that the peer is who it claims to be and 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. that the peer is authorized to carry on the exchange of information. More generally, in order to secure a communications channel, it must More generally, in order to secure a communications channel, it must be possible to verify that messages putatively received from a peer be possible to verify that messages putatively received from a peer skipping to change at page 11, line 7 skipping to change at page 11, line 11 there frequently a requirement for confidentiality. Confidentiality there frequently a requirement for confidentiality. Confidentiality arises at several layers, sometimes simultaneously. For example, arises at several layers, sometimes simultaneously. For example, providers of credit card transaction services want application layer providers of credit card transaction services want application layer privacy, which can be supplied by encrypting application data or by privacy, which can be supplied by encrypting application data or by an encrypted transport layer. If an ISP (or other entity) wants to an encrypted transport layer. If an ISP (or other entity) wants to hide its network structure, it can to encrypt the network layer hide its network structure, it can to encrypt the network layer header. header. 2.3. Network Infrastructure 2.3. Network Infrastructure While these are not critical to the design of a specific system, they While the following protocols are not critical to the design of a are important to running a network, and as such are surveyed here. specific system, they are important to running a network, and as such are surveyed here. 2.3.1. Domain Name System (DNS) 2.3.1. Domain Name System (DNS) The DNS' main function is translating names to numeric IP addresses. The DNS' main function is translating names to numeric IP addresses. While this is not critical to running a network, certain functions While this is not critical to running a network, certain functions are made a lot easier if numeric addresses can be replaced with are made a lot easier if numeric addresses can be replaced with mnemonic names. This facilitates renumbering of networks and mnemonic names. This facilitates renumbering of networks and generally improves the manageability and serviceability of the generally improves the manageability and serviceability of the network. DNS has a set of security extensions called DNSSEC, which network. DNS has a set of security extensions called DNSSEC, which can be used to provide strong cryptographic authentication to that can be used to provide strong cryptographic authentication to the protocol. DNS and DNSSEC are discussed further in Section 3.4.1. DNS. DNS and DNSSEC are discussed further in Section 3.4.1. 2.3.2. Network Management 2.3.2. Network Management Network management has proven to be a difficult problem. As such, Network management has proven to be a difficult problem. As such, various solutions have been proposed, implemented, and deployed. various solutions have been proposed, implemented, and deployed. Each solution has its proponents, all of whom have solid arguments Each solution has its proponents, all of whom have solid arguments for their viewpoints. The IETF has two major network management for their viewpoints. The IETF has two major network management solutions for device operation: SNMP, which is ASN.1-encoded and is solutions for device operation: SNMP, which is ASN.1-encoded and is primarily used for monitoring of system variables and is a polled primarily used for monitoring of system variables and is a polled architecture, and NetConf [RFC4741], which is XML-encoded and architecture, and NetConf [RFC4741], which is XML-encoded and skipping to change at page 11, line 47 skipping to change at page 12, line 5 While the IP Protocol Suite does not have specific solutions for While the IP Protocol Suite does not have specific solutions for secure provisioning and configuration, these problems have been secure provisioning and configuration, these problems have been solved using IP protocols in specifications such as DOCSIS 3.0 solved using IP protocols in specifications such as DOCSIS 3.0 [SP-MULPIv3.0]. [SP-MULPIv3.0]. 3. Specific protocols 3. Specific protocols In this section, having briefly laid out the IP architecture and some In this section, having briefly laid out the IP architecture and some of the problems that the architecture tries to address, we introduce of the problems that the architecture tries to address, we introduce specific protocols that might be appropriate to various Smart Grid specific protocols that might be appropriate to various Smart Grid use cases. Use cases should be analyzed along privacy, AAA, use cases. Use cases should be analyzed along privacy, transport and network solution dimensions. The following sections Authentication, Authorization, and Accounting (AAA), transport and provide guidance for such analyzes. network solution dimensions. The following sections provide guidance for such analyzes. 3.1. Security solutions 3.1. Security solutions As noted, a key consideration in security solutions is a good threat As noted, a key consideration in security solutions is a good threat analysis coupled with appropriate mitigation strategies at each analysis coupled with appropriate mitigation strategies at each layer. The following sections outline the security features of the layer. The following sections outline the security features of the IPS. IPS. 3.1.1. Session identification, authentication, authorization, and 3.1.1. Session identification, authentication, authorization, and accounting accounting skipping to change at page 12, line 34 skipping to change at page 12, line 39 The Security Architecture for the Internet Protocol (IPsec) [RFC4301] The Security Architecture for the Internet Protocol (IPsec) [RFC4301] is a set of control and data protocols that are implemented between is a set of control and data protocols that are implemented between IPv4 and the chosen transport layer, or in IPv6's security extension IPv4 and the chosen transport layer, or in IPv6's security extension header. It allows transport layer sessions to communicate in a way header. It allows transport layer sessions to communicate in a way that is designed to prevent eavesdropping, tampering, or message that is designed to prevent eavesdropping, tampering, or message forgery. As is typical with IETF specifications, the architecture is forgery. As is typical with IETF specifications, the architecture is spelled out in a number of documents which specify the specific spelled out in a number of documents which specify the specific components: the IP Authentication Header (AH) [RFC4302] Encapsulating components: the IP Authentication Header (AH) [RFC4302] Encapsulating Security Payload (ESP) [RFC4303], Internet Key Exchange (IKEv2) Security Payload (ESP) [RFC4303], Internet Key Exchange (IKEv2) [RFC4306], Cryptographic Algorithms [RFC4307], Cryptographic [RFC5996], Cryptographic Algorithms [RFC4307], Cryptographic Algorithm Implementation Requirements for ESP and AH [RFC4835], and Algorithm Implementation Requirements for ESP and AH [RFC4835], and the use of Advanced Encryption Standard (AES) [RFC4309]. the use of Advanced Encryption Standard (AES) [RFC4309]. IPsec provides two modes: Transport mode and tunnel mode. In IPsec provides two modes: Transport mode and tunnel mode. In transport mode, IPsec ESP encrypts the transport layer and the transport mode, IPsec ESP encrypts the transport layer and the application data. In tunnel mode, the source IP datagram is application data. In tunnel mode, the source IP datagram is encrypted and encapsulated in a second IP header addressed to the encrypted and encapsulated in a second IP header addressed to the intended decryptor. As might be expected, tunnel mode is frequently intended decryptor. As might be expected, tunnel mode is frequently used for virtual private networks which need to securely transmit used for virtual private networks which need to securely transmit data across networks with unknown (or no) other security properties. data across networks with unknown (or no) other security properties. In both cases, authentication, authorization, and confidentiality In both cases, authentication, authorization, and confidentiality extend from system to system, and apply to all applications that the extend from system to system, and apply to all applications that the two systems use. 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) 3.1.3. Transport Layer Security (TLS) Transport Layer Security [RFC5246] and Datagram Transport Layer Transport Layer Security [RFC5246] and Datagram Transport Layer Security [RFC4347][I-D.ietf-tls-rfc4347-bis] are mechanisms that Security [RFC4347][I-D.ietf-tls-rfc4347-bis] are mechanisms that travel within the transport layer protocol data unit, meaning that travel within the transport layer protocol data unit, meaning that they readily traverse network address translators and secure the they readily traverse network address translators and secure the information exchanges without securing the datagrams exchanged or the information exchanges without securing the datagrams exchanged or the transport layer itself. Each allows client/server applications to transport layer itself. Each allows client/server applications to communicate in a way that is designed to prevent eavesdropping, communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. Authentication, authorization, and tampering, or message forgery. Authentication, authorization, and confidentiality exist for a session between specific applications. confidentiality exist for a session between specific applications. When used in conjunction with IEEE 802.1X [IEEE802.1X], EAP-TLS In order to communicate securely, an TLS client and TLS server must [RFC5216] is widely considered to offer excellent access security to agree on the cryptographic algorithms and keys that they will use on a wired or wireless IEEE 802 LAN (IEEE 802.1X in conjunction with the secured connection. In particular, they must agree on these EAP-TLS is the baseline for Zigbee SEP 2.0). Note that one potential items: drawback of 802.1X technology is that it requires deployment of client-side certificates, which is frequently seen as a deployment o Key Establishment Algorithm barrier. o Peer Authentication Algorithm o Bulk Data Encryption Algorithm and key size o Digest Algorithm Since each categories has multiple options, the number of possible combinations is large. As a result, TLS does not allow all possible combinations of choices; rather it only allows certain well-defined combinations known as Cipher Suites. [IEC62351-3] outlines the use of different TLS Cipher Suites for use in the Smart Grid. When used in conjunction with IEEE 802.1X [IEEE802.1X], both EAP-TLS [RFC5216] and the Protocol for Carrying Authentication for Network Access (PANA) [RFC5193] are widely considered to offer excellent access security to a wired or wireless IEEE 802 LAN (IEEE 802.1X in conjunction with EAP-TLS is the baseline for Zigbee SEP 2.0). 3.1.4. Secure/Multipurpose Internet Mail Extensions (S/MIME) 3.1.4. Secure/Multipurpose Internet Mail Extensions (S/MIME) The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049] The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049] [RFC5750] [RFC5751] [RFC4262] specification was originally designed [RFC5750] [RFC5751] [RFC4262] specification was originally designed as an extension to SMTP Mail to provide evidence that the putative 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 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 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 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 be exchanged, by any means, and has become one of the most common skipping to change at page 15, line 19 skipping to change at page 16, line 6 [I-D.ietf-behave-address-format] [I-D.ietf-behave-address-format] o DNS extensions [I-D.ietf-behave-dns64] o DNS extensions [I-D.ietf-behave-dns64] o IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate] o IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate] o Translation from IPv6 Clients to IPv4 Servers o Translation from IPv6 Clients to IPv4 Servers [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate-stateful] As with IPv4/IPv4 Network Address Translation, translation between As with IPv4/IPv4 Network Address Translation, translation between IPv4 and IPv6 has limited real world applicability: any application IPv4 and IPv6 has limited real world applicability for an application protocol that carries IP addresses and expects them to be meaningful protocol which carry IP addresses in its payload and expects those to both client and server or to both peers will have trouble when the addresses to be meaningful to both client and server. However, for addresses are transparently translated. However, for those protocols those protocols that do not, protocol translation can provide a that do not, protocol translation can provide a useful network useful network extension. extension. Network-based translation provides for two types of services: Network-based translation provides for two types of services: stateless (and therefore scalable and load-sharable) translation stateless (and therefore scalable and load-sharable) translation between IPv4 and IPv6 addresses that embed an IPv4 address in them, between IPv4 and IPv6 addresses that embed an IPv4 address in them, and stateful translation similar to IPv4/IPv4 translation between and stateful translation similar to IPv4/IPv4 translation between IPv4 addresses. The stateless mode is straightforward to implement, IPv4 addresses. The stateless mode is straightforward to implement, but due to the embedding, requires IPv4 addresses to be allocated to but due to the embedding, requires IPv4 addresses to be allocated to an otherwise IPv6-only network, and is primarily useful for IPv4- an otherwise IPv6-only network, and is primarily useful for IPv4- accessible servers implemented in the IPv6 network. The stateful accessible servers implemented in the IPv6 network. The stateful mode allows clients in the IPv6 network to access servers in the IPv4 mode allows clients in the IPv6 network to access servers in the IPv4 network, but does not provide such service for IPv4 clients accessing network, but does not provide such service for IPv4 clients accessing IPv6 peers or servers with general addresses; it does however have IPv6 peers or servers with general addresses; it does however have the advantage that it does not require that a unique IPv4 address be the advantage that it does not require that a unique IPv4 address be embedded in the IPv6 address of hosts using this mechanism. 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 3.2.2. Internet Protocol Version 4 IPv4 [RFC0791] and the Internet Control Message Protocol [RFC0792] IPv4 [RFC0791] and the Internet Control Message Protocol [RFC0792] comprise the IPv4 network layer. IPv4 provides unreliable delivery comprise the IPv4 network layer. IPv4 provides unreliable delivery of datagrams. of datagrams. IPv4 also provides for fragmentation and reassembly of long datagrams IPv4 also provides for fragmentation and reassembly of long datagrams for transmission through networks with small Maximum Transmission for transmission through networks with small Maximum Transmission Units (MTU). The MTU is the largest packet size that can be Units (MTU). The MTU is the largest packet size that can be delivered across the network. In addition, the IPS provides the delivered across the network. In addition, the IPS provides the skipping to change at page 16, line 15 skipping to change at page 17, line 6 IPv4 originally supported an experimental type of service field that IPv4 originally supported an experimental type of service field that identified eight levels of operational precedence styled after the identified eight levels of operational precedence styled after the requirements of military telephony, plus three and later four bit requirements of military telephony, plus three and later four bit flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2 flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2 [RFC2328] interpreted as control traffic; this control traffic is [RFC2328] interpreted as control traffic; this control traffic is assured of not being dropped when queued or upon receipt even if assured of not being dropped when queued or upon receipt even if other traffic is being dropped.. These control bits turned out to be other traffic is being dropped.. These control bits turned out to be less useful than the designers had hoped. They were replaced by the less useful than the designers had hoped. They were replaced by the Differentiated Services Architecture [RFC2474][RFC2475], which Differentiated Services Architecture [RFC2474][RFC2475], which contains a six bit code point used to select an algorithm (a "per-hop contains a six bit code point used to select an algorithm (a "per-hop behavior") to be applied to the datagram. 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 3.2.2.1. IPv4 Address Allocation and Assignment IPv4 addresses are administratively assigned, usually using automated IPv4 addresses are administratively assigned, usually using automated methods, and assigned using the Dynamic Host Configuration Protocol methods, and assigned using the Dynamic Host Configuration Protocol (DHCP) [RFC2131]. On most interface types, neighboring equipment (DHCP) [RFC2131]. On most interface types, neighboring equipment identify each other's addresses using Address Resolution Protocol identify each other's addresses using Address Resolution Protocol (ARP) [RFC0826]. (ARP) [RFC0826]. 3.2.2.2. IPv4 Unicast Routing 3.2.2.2. IPv4 Unicast Routing skipping to change at page 20, line 41 skipping to change at page 21, line 32 can be used in other forms of ad hoc networks. It provides arbitrary can be used in other forms of ad hoc networks. It provides arbitrary connectivity between device within a distributed subnet. As with connectivity between device within a distributed subnet. As with protocols designed for wired networks, routing is calculated and protocols designed for wired networks, routing is calculated and maintained whenever changes are detected, and maintained in each maintained whenever changes are detected, and maintained in each router's tables. The set of nodes that operate as routers within the router's tables. The set of nodes that operate as routers within the subnet, however, are fairly fluid, and dependent on this subnet, however, are fairly fluid, and dependent on this instantaneous topology of the subnet. instantaneous topology of the subnet. 3.2.4.7. Routing for Low power and Lossy Networks 3.2.4.7. Routing for Low power and Lossy Networks The RPL: IPv6 Routing Protocol for Low power and Lossy Networks The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) [I-D.ietf-roll-rpl] xxx [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. 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 3.2.5. IPv6 Multicast Forwarding and Routing IPv6 specifies both unicast and multicast datagram exchange. This IPv6 specifies both unicast and multicast datagram exchange. This uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710] uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710] [RFC3590] [RFC3810] [RFC4604] to enable applications to join [RFC3590] [RFC3810] [RFC4604] to enable applications to join multicast groups, and for most applications uses Source-Specific multicast groups, and for most applications uses Source-Specific Multicast [RFC4607] for routing and delivery of multicast messages. Multicast [RFC4607] for routing and delivery of multicast messages. The mechanisms experimentally developed for reliable multicast in The mechanisms experimentally developed for reliable multicast in IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well. IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well. 3.2.5.1. Protocol-Independent Multicast Routing 3.2.5.1. Protocol-Independent Multicast Routing xxx Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol A multicast routing protocol has two basic functions: Building the Specification (Revised) [RFC3973] xxx Protocol Independent Multicast 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] - Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601] xxx Source-Specific Multicast (SSM) [RFC3569] xxx Source-Specific were designed for the ASM model. Protocol Independent Multicast [RFC4608] xxx Authentication and Confidentiality in Protocol Independent Multicast Sparse Mode Many modern multicast deployments use Source-Specific Multicast (PIM- (PIM-SM) Link-Local Messages [RFC5796] xxx 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 tress are rooted the sending host (called an "(S,G) tree"). Since only the source S can send on to the group, SSM has inherent anti-jamming capability. In addition, inter-domain multicast is simplified since it is the responsibility of the receivers (rather than the network) to find the (S,G) channel they are interested in receiving. This implies that SSM requires some form of directory service so that receivers can find the (S,G) channels. 3.2.6. Adaptation to lower layer networks and link layer protocols 3.2.6. Adaptation to lower layer networks and link layer protocols In general, the layered architecture of the Internet enables the IPS In general, the layered architecture of the Internet enables the IPS to run over any appropriate layer two architecture. The ability to to run over any appropriate layer two architecture. The ability to change the link or physical layer without having to rethink the change the link or physical layer without having to rethink the network layer, transports, or applications has been a great benefit network layer, transports, or applications has been a great benefit in the Internet. in the Internet. Examples of link layer adaptation technology include: Examples of link layer adaptation technology include: skipping to change at page 24, line 40 skipping to change at page 26, line 25 [RFC2131] or DHCPv6 [RFC3315]. The best argument for the use of [RFC2131] or DHCPv6 [RFC3315]. The best argument for the use of autoconfiguration is a large number of systems that require little autoconfiguration is a large number of systems that require little more than a random number as an address; the argument for DHCP is more than a random number as an address; the argument for DHCP is administrative control. administrative control. There are other parameters that may need to be allocated to hosts There are other parameters that may need to be allocated to hosts which require administrative configuration; examples include the which require administrative configuration; examples include the addresses of DNS servers, keys for Secure DNS and Network Time addresses of DNS servers, keys for Secure DNS and Network Time servers. servers. 3.5. Service and Resource Discovery 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. 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] 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 Service and resource discovery are among the most important protocols for constrained resource self-organizing networks. These include for constrained resource self-organizing networks. These include various sensor networks as well as the Home Area Networks (HANs), various sensor networks as well as the Home Area Networks (HANs), Building Area Networks (BANs) and Field Area Networks (FANs) Building Area Networks (BANs) and Field Area Networks (FANs) envisioned by Smart Grid architects. envisioned by Smart Grid architects. 3.5.1. Service Discovery 3.6.1. Service Discovery Service discovery protocols are designed for the automatic Service discovery protocols are designed for the automatic configuration and detection of devices, and the services offered by configuration and detection of devices, and the services offered by the discovered devices. In many cases service discovery is performed the discovered devices. In many cases service discovery is performed by so-called "constrained resource" devices (i.e., those with limited by so-called "constrained resource" devices (i.e., those with limited processing power, memory, and power resources). processing power, memory, and power resources). In general, service discovery is concerned with the assignment of In general, service discovery is concerned with the resolution and network addresses (perhaps via Stateless Address Autoconfiguration distribution of hostnames via multicast DNS [RFC4862]), resolution and distribution of hostnames via multicast [I-D.cheshire-dnsext-multicastdns] and the automatic location of DNS [I-D.cheshire-dnsext-multicastdns] and the automatic location of network services via DHCP (Section 3.4.2), the DNS Service Discovery 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 (DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part of Apple's Bonjour technology), and the Service Location Protocol (SLP) [RFC2608]. technology) and the Service Location Protocol (SLP) [RFC2608]. 3.5.2. Resource Discovery 3.6.2. Resource Discovery Resource Discovery is concerned with the discovery resources offered Resource Discovery is concerned with the discovery of resources by end-points and is extremely important in machine-to-machine offered by end-points and is extremely important in machine-to- closed-loop applications (i.e., those with no humans in the loop). machine closed-loop applications (i.e., those with no humans in the The goals of resource discover protocols include: loop). The goals of resource discover protocols include: Simplicity of creation and maintenance of resources Simplicity of creation and maintenance of resources Commonly understood semantics Commonly understood semantics Conformance to existing and emerging standards Conformance to existing and emerging standards International scope and applicability International scope and applicability Extensibility Extensibility Interoperability among collections and indexing systems Interoperability among collections and indexing systems The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is being developed in IETF with these goals in mind. In particular, being developed in IETF with these goals in mind. In particular, CoAP is designed for use in constrained resource networks and for CoAP is designed for use in constrained resource networks and for machine-to-machine applications such as smart energy and building machine-to-machine applications such as smart energy and building automation. It provides a RESTful transfer protocol, a built-in automation. It provides a RESTful transfer protocol [RESTFUL], a resource discovery protocol, and includes web concepts such as URIs built-in resource discovery protocol, and includes web concepts such and content-types. CoAP provides both unicast and multicast resource as URIs and content-types. CoAP provides both unicast and multicast discovery and includes the ability to filter on attributes of resource discovery and includes the ability to filter on attributes resource descriptions. Finally, CoAP resource discovery can also be of resource descriptions. Finally, CoAP resource discovery can also used to discovery HTTP resources. be used to discovery HTTP resources. For simplicity, CoAP makes the assumption that all CoAP servers For simplicity, CoAP makes the assumption that all CoAP servers listen on the default CoAP port or otherwise have been configured or listen on the default CoAP port or otherwise have been configured or discovered using some general service discovery mechanism such as DNS discovered using some general service discovery mechanism such as DNS Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd]. Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd]. Resource discovery in CoAP is accomplished through the use of well- Resource discovery in CoAP is accomplished through the use of well- known resources which describe the links offered by a CoAP server. known resources which describe the links offered by a CoAP server. CoAP defines a well-known URI for discovery: "/.well-known/r" CoAP defines a well-known URI for discovery: "/.well-known/r" [RFC5785]. For example, the query [GET /.well-known/r] returns a [RFC5785]. For example, the query [GET /.well-known/r] returns a list of links (representing resources) available from the queried list of links (representing resources) available from the queried CoAP server. A query such as [GET /.well-known/r?n=Voltage] returns CoAP server. A query such as [GET /.well-known/r?n=Voltage] returns the resources with the name Voltage. the resources with the name Voltage. 3.6. Other Applications 3.7. Other Applications There are several applications that are widely used but are not There are several applications that are widely used but are not properly thought of as infrastructure. properly thought of as infrastructure. 3.6.1. Network Time 3.7.1. Session Initiation Protocol 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]. NTP is currently being updated in [RFC5905]. 3.6.2. Session Initiation Protocol The Session Initiation Protocol The Session Initiation Protocol [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is an [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is an application layer control (signaling) protocol for creating, application layer control (signaling) protocol for creating, modifying and terminating multimedia sessions on the Internet, meant modifying and terminating multimedia sessions on the Internet, meant to be more scalable than H.323. Multimedia sessions can be voice, to be more scalable than H.323. Multimedia sessions can be voice, video, instant messaging, shared data, and/or subscriptions of video, instant messaging, shared data, and/or subscriptions of events. SIP can run on top of TCP, UDP, SCTP, or TLS over TCP. SIP 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 is independent of the transport layer, and independent of the underlying IPv4/v6 version. In fact, the transport protocol used can underlying IPv4/v6 version. In fact, the transport protocol used can skipping to change at page 27, line 10 skipping to change at page 30, line 11 designed to be SDP aware (i.e., looking into each packet far enough 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 to discover what the IP address and port number is for this particular session - and resetting it based on the Session Traversal particular session - and resetting it based on the Session Traversal Utilities for NAT [RFC5389], the session established by SIP will not Utilities for NAT [RFC5389], the session established by SIP will not result in RTP packets being sent to the proper endpoint (in SIP 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 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 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 learn about the presence of the NATs that prevent the RTP packets from being received by the UA establishing the session. from being received by the UA establishing the session. 3.6.3. Calendaring 3.7.2. Calendaring Internet calendaring, as implemented in Apple iCal, Microsoft Outlook Internet calendaring, as implemented in Apple iCal, Microsoft Outlook and Entourage, and Google Calendar, is specified in Internet and Entourage, and Google Calendar, is specified in Internet Calendaring and Scheduling Core Object Specification (iCalendar) Calendaring and Scheduling Core Object Specification (iCalendar) [RFC5545] and is in the process of being updated to an XML schema in [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] iCalendar XML Representation [I-D.daboo-et-al-icalendar-in-xml] Several protocols exist to carry calendar events, including iCalendar Several protocols exist to carry calendar events, including iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the Message-Based Interoperability Protocol (iMIP) [RFC2447] , and open Message-Based Interoperability Protocol (iMIP) [RFC2447] , and open source work on the Atom Publishing Protocol [RFC5023]. source work on the Atom Publishing Protocol [RFC5023]. skipping to change at page 32, line 17 skipping to change at page 35, line 17 therefore be removed upon publication as an RFC at the RFC Editor's therefore be removed upon publication as an RFC at the RFC Editor's discretion. discretion. 6. Security Considerations 6. Security Considerations Security is addressed in some detail in Section 2.2 and Section 3.1. Security is addressed in some detail in Section 2.2 and Section 3.1. 7. Acknowledgements 7. Acknowledgements Review comments were made by Andrew Yourtchenko, Ashok Narayanan, Review comments were made by Andrew Yourtchenko, Ashok Narayanan, Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, Hemant Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, Don Singh, James Polk, John Meylor, Joseph Salowey, Julien Abeille, Kerry Sturek, Francis Cleveland, Hemant Singh, James Polk, John Meylor, Lynn, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman, Joseph Salowey, Julien Abeille, Kerry Lynn, Magnus Westerlund, Ralph Droms, Russ White, Sheila Frankel, and Toerless Eckert. Dave Murtaza Chiba, Paul Duffy, Paul Hoffman, Ralph Droms, Russ White, McGrew, Vint Cerf, and Ralph Droms suggested text. Sheila Frankel, Tom Herbst, and Toerless Eckert. Dave McGrew, Vint Cerf, and Ralph Droms suggested text. 8. References 8. References 8.1. Normative References 8.1. Normative References [RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. and Support", STD 3, RFC 1123, October 1989. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. RFC 1812, June 1995. [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006. April 2006. 8.2. Informative References 8.2. Informative References [1822] Bolt Beranek and Newman Inc., "Interface Message Processor -- Specifications for the interconnection of a host and a IMP, Report No. 1822", January 1976. [I-D.arkko-ipv6-transition-guidelines] [I-D.arkko-ipv6-transition-guidelines] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms", Transition Mechanisms during IPv6 Deployment", draft-arkko-ipv6-transition-guidelines-03 (work in draft-arkko-ipv6-transition-guidelines-06 (work in progress), July 2010. progress), August 2010. [I-D.cheshire-dnsext-dns-sd] [I-D.cheshire-dnsext-dns-sd] Cheshire, S. and M. Krochmal, "DNS-Based Service Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", draft-cheshire-dnsext-dns-sd-06 (work in Discovery", draft-cheshire-dnsext-dns-sd-06 (work in progress), March 2010. progress), March 2010. [I-D.cheshire-dnsext-multicastdns] [I-D.cheshire-dnsext-multicastdns] Cheshire, S. and M. Krochmal, "Multicast DNS", Cheshire, S. and M. Krochmal, "Multicast DNS", draft-cheshire-dnsext-multicastdns-11 (work in progress), draft-cheshire-dnsext-multicastdns-11 (work in progress), March 2010. March 2010. [I-D.daboo-et-al-icalendar-in-xml] [I-D.daboo-et-al-icalendar-in-xml] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML Daboo, C., Douglass, M., and S. Lees, "xCal: The XML format for iCalendar", format for iCalendar", draft-daboo-et-al-icalendar-in-xml-05 (work in progress), draft-daboo-et-al-icalendar-in-xml-06 (work in progress), July 2010. September 2010. [I-D.ietf-6lowpan-hc] [I-D.ietf-6lowpan-hc] Hui, J. and P. Thubert, "Compression Format for IPv6 Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-08 Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-12 (work in progress), July 2010. (work in progress), September 2010. [I-D.ietf-6man-node-req-bis] [I-D.ietf-6man-node-req-bis] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node Requirements RFC 4294-bis", Requirements RFC 4294-bis", draft-ietf-6man-node-req-bis-05 (work in progress), draft-ietf-6man-node-req-bis-05 (work in progress), July 2010. July 2010. [I-D.ietf-behave-address-format] [I-D.ietf-behave-address-format] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", Li, "IPv6 Addressing of IPv4/IPv6 Translators", draft-ietf-behave-address-format-10 (work in progress), draft-ietf-behave-address-format-10 (work in progress), August 2010. August 2010. [I-D.ietf-behave-dns64] [I-D.ietf-behave-dns64] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS extensions for Network Address Translation "DNS64: DNS extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", from IPv6 Clients to IPv4 Servers", draft-ietf-behave-dns64-10 (work in progress), July 2010. draft-ietf-behave-dns64-11 (work in progress), October 2010. [I-D.ietf-behave-v6v4-framework] [I-D.ietf-behave-v6v4-framework] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", IPv4/IPv6 Translation", draft-ietf-behave-v6v4-framework-10 (work in progress), draft-ietf-behave-v6v4-framework-10 (work in progress), August 2010. August 2010. [I-D.ietf-behave-v6v4-xlate] [I-D.ietf-behave-v6v4-xlate] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", draft-ietf-behave-v6v4-xlate-21 (work in Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in progress), August 2010. progress), September 2010. [I-D.ietf-behave-v6v4-xlate-stateful] [I-D.ietf-behave-v6v4-xlate-stateful] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", Clients to IPv4 Servers", draft-ietf-behave-v6v4-xlate-stateful-12 (work in draft-ietf-behave-v6v4-xlate-stateful-12 (work in progress), July 2010. progress), July 2010. [I-D.ietf-core-coap] [I-D.ietf-core-coap] Shelby, Z., Frank, B., and D. Sturek, "Constrained Shelby, Z., Frank, B., and D. Sturek, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-01 Application Protocol (CoAP)", draft-ietf-core-coap-02 (work in progress), July 2010. (work in progress), September 2010. [I-D.ietf-manet-dymo] [I-D.ietf-manet-dymo] Chakeres, I. and C. Perkins, "Dynamic MANET On-demand Chakeres, I. and C. Perkins, "Dynamic MANET On-demand (DYMO) Routing", draft-ietf-manet-dymo-21 (work in (DYMO) Routing", draft-ietf-manet-dymo-21 (work in progress), July 2010. progress), July 2010. [I-D.ietf-roll-rpl] [I-D.ietf-roll-rpl] Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-11 (work in progress), July 2010. draft-ietf-roll-rpl-11 (work in progress), July 2010. [I-D.ietf-tls-rfc4347-bis] [I-D.ietf-tls-rfc4347-bis] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security version 1.2", draft-ietf-tls-rfc4347-bis-04 (work Security version 1.2", draft-ietf-tls-rfc4347-bis-04 (work in progress), July 2010. in progress), July 2010. [IEC62351-3] International Electrotechnical Commission Technical Committee 57, "POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION EXCHANGE. DATA AND COMMUNICATIONS SECURITY -- Part 3: Communication network and system security Profiles including TCP/IP", May 2007. [IEEE802.1X] [IEEE802.1X] Institute of Electrical and Electronics Engineers, "IEEE Institute of Electrical and Electronics Engineers, "IEEE Standard for Local and Metropolitan Area Networks - Port Standard for Local and Metropolitan Area Networks - Port based Network Access Control", IEEE Standard 802.1X-2010, based Network Access Control", IEEE Standard 802.1X-2010, February 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, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. August 1980. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. September 1981. [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. RFC 792, September 1981. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, skipping to change at page 38, line 37 skipping to change at page 42, line 5 March 2002. March 2002. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. 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. [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002. [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002. RFC 3436, December 2002. [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction M., and J. Crowcroft, "The Use of Forward Error Correction skipping to change at page 40, line 34 skipping to change at page 44, line 36 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. RFC 4303, December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005. December 2005. [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM [RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)", Mode with IPsec Encapsulating Security Payload (ESP)", RFC 4309, December 2005. RFC 4309, December 2005. [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Session Initiation Protocol's (SIP) Non-INVITE skipping to change at page 41, line 23 skipping to change at page 45, line 23 Message Protocol (ICMPv6) for the Internet Protocol Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006. Version 6 (IPv6) Specification", RFC 4443, March 2006. [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile IPv6 and Firewalls: Problem Statement", RFC 4487, IPv6 and Firewalls: Problem Statement", RFC 4487, May 2006. May 2006. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 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, [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 2006. [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for Source- Specific Multicast", RFC 4604, August 2006. Specific Multicast", RFC 4604, August 2006. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for skipping to change at page 41, line 46 skipping to change at page 45, line 50 Protocol Independent Multicast in 232/8", BCP 120, Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006. RFC 4608, August 2006. [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006. Documents", RFC 4614, September 2006. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. 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, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. January 2007. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. RFC 4787, January 2007. [RFC4835] Manral, V., "Cryptographic Algorithm Implementation [RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Requirements for Encapsulating Security Payload (ESP) and skipping to change at page 43, line 10 skipping to change at page 47, line 25 PPP", RFC 5072, September 2007. PPP", RFC 5072, September 2007. [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- Peer (P2P) Communication across Network Address Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008. Translators (NATs)", RFC 5128, March 2008. [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Network Address Translator (NAT) and a Network Address Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. 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 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008. Communication", RFC 5207, April 2008. [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008. Authentication Protocol", RFC 5216, March 2008. [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008. RFC 5238, May 2008. [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008. [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008. [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008. October 2008. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. October 2008. [RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, [RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, "Addressing an Amplification Vulnerability in Session "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", RFC 5393, Initiation Protocol (SIP) Forking Proxies", RFC 5393, December 2008. December 2008. [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, for Application Designers", BCP 145, RFC 5405, November 2008. November 2008. [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009. [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, Core Object Specification (iCalendar)", RFC 5545, September 2009. September 2009. [RFC5546] Daboo, C., "iCalendar Transport-Independent [RFC5546] Daboo, C., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, Interoperability Protocol (iTIP)", RFC 5546, December 2009. December 2009. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. Infrastructures (6rd)", RFC 5569, January 2010. [RFC5621] Camarillo, G., "Message Body Handling in the Session [RFC5621] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, September 2009. 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 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009. 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, [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009. Protocol", RFC 5740, November 2009. [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Mail Extensions (S/MIME) Version 3.2 Certificate Handling", RFC 5750, January 2010. Handling", RFC 5750, January 2010. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785, April 2010. April 2010. [RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Confidentiality in Protocol Independent Multicast Sparse Routing Requirements in Low-Power and Lossy Networks", Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010. RFC 5826, April 2010. [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010. 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. [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. Specification", RFC 5905, June 2010. [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [SP-MULPIv3.0] [SP-MULPIv3.0] CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.0-I10-090529", Interface Specification, CM-SP-MULPIv3.0-I10-090529", May 2009. 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. --- 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 * 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 (Homeplug), IEEE 802.15.4g (Zigbee), and IEEE 802.11 (WiFi, commonly deployed today and used by some high end appliances). It is reasonable to expect other technologies to be developed in the future. As the Zigbee Alliance has learned (and as a resulted incorporated the IPS in Secure Energy Profile 2.0), there is significant value in providing a virtual address that is mapped to interfaces or nodes attached to each of those technologies. There are two possible communication models within the HAN, both of which are likely to be useful. Devices may communicate directly with each other, or they may be managed by some central controller. An example of direct communications might be a light switch that directly commands a lamp to turn on or off. An example of indirect communications might be a control application in a Customer or Building that accepts telemetry from a thermostat, applies some form of policy, and controls the heating and air conditioning systems. In addition, there are high end appliances in the market today that use residential broadband to communicate with their manufacturers, and obviously the meter needs to communicate with the utility. Utility NAN / / +----+-----+ +--+ +--+ +--+ | Meter | |D1| |D2| |D3| +-----+----+ ++-+ ++-+ ++-+ | | | | ----+-+-------+----+----+---- IEEE 802.15.4 | +--+---+ |Router+------/------ Residential Broadband +--+---+ | ----+---------+----+----+---- IEEE P1901 | | | ++-+ ++-+ ++-+ |D4| |D5| |D6| +--+ +--+ +--+ Figure 7: Home Area Network Figure 7 shows a simple network containing IEEE 802.15.4 and IEEE 1901 domains. It shows the connectivity between them as a router separate from the EMS. This is for clarity; the two could of course be incorporated into a single system, and one could imagine appliances that want to communicate with their manufacturers supporting both a HAN interface and a WiFi interface rather than depending on the router. These are all manufacturer design decisions. A.1.1. HAN Routing The HAN can be seen as communicating with two kinds of non-HAN networks. One is the home LAN, which may in turn be attached to the Internet, and will generally either derive its prefix from the upstream ISP or use a self-generated ULA. Another is the utility's NAN, which through an ESI provides utility connectivity to the HAN; in this case the HAN will be addressed by a self-generated ULA (note, however, that in some cases ESI may also provide a prefix via DHCP [RFC3315]). In addition, the HAN will have link-local addresses that can be used between neighboring nodes. In general, an HAN will be comprised of both 802.15.4, 802.11 (and possibly other) networks. The ESI is node on the user's residential network, and will not typically provide stateful packet forwarding or firewall services between the HAN and the utility network(s). In general, the meter/ ESI is just a node on the home network. However, the ESI must be capable of understanding that most home networks are not 802.15.4 enabled (rather, they are typically 802.11 networks), and that it must be capable of setting up ad-hoc networks between various sensors in the home (e.g., betweeen the meter and say, a thermostat) in the event there aren't other networks available. A.1.2. HAN Security In any network, we have a variety of threats and a variety of possible mitigations. These include, at minimum: Link Layer: Why is your machine able to talk in my network? The WiFi SSIDs often use some form of authenticated access control, which may be a simple encrypted password mechanism or may use a combination of encryption and IEEE 802.1X+EAP-TLS Authentication/ Authorization to ensure that only authorized communicants can use it. If a LAN has a router attached, the router may also implement a firewall to filter remote accesses. Network Layer: Given that your machine is authorized access to my network, why is your machine talking with my machine? IPsec is a way of ensuring that computers that can use a network are allowed to talk with each other, may also enforce confidentiality, and may provide VPN services to make a device or network appear to be part of a remote network. Application: Given that your machine is authorized access to my network and my machine, why is your application talking with my application? The fact that your machine and mine are allowed to talk for some applications doesn't mean they are allowed to for all applications. (D)TLS, https, and other such mechanisms enable an application to impose application-to-application controls similar to the network layer controls provided by IPsec. Remote Application: How do I know that the data I received is the data you sent? Especially in applications like electronic mail, where data passes through a number of intermediaries that one may or may not really want munging it (how many times have you seen a URL broken by a mail server?), we have tools (DKIM, S/MIME, and W3C XML Signatures to name a few) to provide non-repudiability and integrity verification. This may also have legal ramifications: if a record of a meter reading is to be used in billing, and the bill is disputed in court, one could imagine the court wanting proof that the record in fact came from that meter at that time and contained that data. Application-specific security: In addition, applications often provide security services of their own. The fact that I can access a file system, for example, doesn't mean that I am authorized to access everything in it; the file system may well prevent my access to some of its contents. Routing protocols like BGP obsess with the question "what statements that my peer made am I willing to believe". And monitoring protocols like SNMP may not be willing to answer every question they are asked, depending on access configuration. Devices in the HAN want controlled access to the LAN in question for obvious reasons. In addition, there should be some form of mutual authentication between devices - the lamp controller will want to know that the light switch telling it to change state is the right light switch, for example. The EMS may well want strong authentication of accesses - the parents may not want the children changing the settings, and while the utility and the customer are routinely granted access, other parties (especially parties with criminal intent) need to be excluded. A.2. Model 1: AMI with separated domains With the background given in Appendix A.1, 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, QoS issues reportedly arise when high precedence messages must be sent through the collector to the home; if the collector is occupied polling the meters or doing some other task, the application may not yield control of the processor to the application that services the message. Clearly, this is either an application or an OS problem; applications need to be designed in a manner that doesn't block high precedence messages. The collector also needs to use appropriate NAN services, if they exist, to provide the NAN QoS it needs. For example, if WiMax is in use, it might use a routine-level service for normal exchanges but a higher precedence service for these messages. A.3. Model 2: AMI with neighborhood access to the home In this second model, let's imagine that the utility directly accesses appliances within the HAN. Rather than expect an EMS to respond to price signals in Demand Response, it directly commands devices like air conditioners to change state, or throws relays on circuits to or within the home. +----------+ +--+ +--+ +--+ | Meter | |D1| |D2| |D3| +-----+----+ ++-+ ++-+ ++-+ | | | | ----+-+-------+----+----+---- IEEE 802.15.4 | +--+---+ | +------/------ NAN |Router| | +------/------ Residential Broadband +--+---+ | ----+---------+----+----+---- IEEE P1901 | | | ++-+ ++-+ ++-+ |D4| |D5| |D6| +--+ +--+ +--+ 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 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 Authors' Addresses Fred Baker Fred Baker Cisco Systems Cisco Systems Santa Barbara, California 93117 Santa Barbara, California 93117 USA USA Email: fred@cisco.com Email: fred@cisco.com David Meyer David Meyer End of changes. 60 change blocks. 149 lines changed or deleted 758 lines changed or added This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/