[smartpowerdir] Diff: draft-baker-ietf-core-07.txt

[smartpowerdir] Diff: draft-baker-ietf-core-07.txt - sg-ietf-compendium.txt

Fred Baker <fred@cisco.com> Mon, 25 October 2010 18:46 UTC

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)
Content-Type: multipart/alternative; boundary=Apple-Mail-46-487591200
Subject: [smartpowerdir] Diff: draft-baker-ietf-core-07.txt - sg-ietf-compendium.txt
Precedence: list

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

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/

[smartpowerdir] Diff: draft-baker-ietf-core-07.tx… Fred Baker