One document matched: draft-baker-ietf-core-14.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!--
#
# sg-ietf-compendium.xml
#
# aka draft-baker-ietf-core
#
# David Meyer
# dmm@1-4-5.net
# Tue Aug 10 06:38:22 PDT 2010
#
# $Header: /mnt/disk0/dmm/IETF/Drafts/active/ietf-core/RCS/sg-ietf-compendium.xml,v 1.17 2010/10/25 17:25:46 dmm Exp $
#
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- Some of the more generally applicable PIs that most I-Ds might want to use -->
<!-- Try to enforce the ID-nits conventions and DTD validity -->
<?rfc strict="yes" ?>
<!-- Items used when reviewing the document -->
<?rfc comments="no" ?>
<!-- Controls display of <cref> elements -->
<?rfc inline="no" ?>
<!-- When no, put comments at end in comments section, otherwise, put inline -->
<?rfc editing="no" ?>
<!-- When yes, insert editing marks: editing marks consist of a
string such as <29> printed in the blank line at the
beginning of each paragraph of text. -->
<!-- Create Table of Contents (ToC) and set some options for it.
Note the ToC may be omitted for very short documents,but idnits insists on a ToC
if the document has more than 15 pages. -->
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<!-- If "yes" eliminates blank lines before main section entries. -->
<?rfc tocdepth="4"?>
<!-- Sets the number of levels of sections/subsections... in ToC -->
<!-- Choose the options for the references.
Some like symbolic tags in the references (and citations) and others prefer
numbers. The RFC Editor always uses symbolic tags.
The tags used are the anchor attributes of the references. -->
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<!-- If "yes", causes the references to be sorted in order of tags.
This doesn't have any effect unless symrefs is "yes" also. -->
<!-- These two save paper: Just setting compact to "yes" makes savings by not starting each
main section on a new page but does not omit the blank lines between list items.
If subcompact is also "yes" the blank lines between list items are also omitted. -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<!-- end of list of popular I-D processing instructions -->
<!-- end of list of processing instructions -->
<rfc category="info" docName="draft-baker-ietf-core-14" ipr="trust200902">
<front>
<title abbrev="Internet Protocols for the Smart Grid">Internet Protocols
for the Smart Grid</title>
<author fullname="Fred Baker" initials="F.J." surname="Baker">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Santa Barbara</city>
<code>93117</code>
<region>California</region>
<country>USA</country>
</postal>
<email>fred@cisco.com</email>
</address>
</author>
<author fullname="David Meyer" initials="D.M." surname="Meyer">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Eugene</city>
<code>97403</code>
<region>Oregon</region>
<country>USA</country>
</postal>
<email>dmm@cisco.com</email>
</address>
</author>
<date year="2011" />
<area>General</area>
<workgroup></workgroup>
<abstract>
<t>This note identifies the key infrastructure protocols of the Internet
Protocol Suite for use in the Smart Grid. The target audience is those
people seeking guidance on how to construct an appropriate Internet
Protocol Suite profile for the Smart Grid. In practice, such a profile
would consist of selecting what is needed for Smart Grid deployment from
the picture presented here.</t>
</abstract>
<!--
<note title="Foreword">
</note>
-->
<!--
<note title="Requirements">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119"/>.</t>
</note>
-->
<!--
<?rfc needLines="10" ?>
<texttable anchor="table_example" title="A Very Simple Table">
<preamble>Tables use ttcol to define column headers and widths.
Every cell then has a "c" element for its content.</preamble>
<ttcol align="center">ttcol #1</ttcol>
<ttcol align="center">ttcol #2</ttcol>
<c>c #1</c> <c>c #2</c>
<c>c #3</c> <c>c #4</c>
<c>c #5</c> <c>c #6</c>
<postamble>which is a very simple example.</postamble>
</texttable>
-->
</front>
<middle>
<!--
<t>There are multiple list styles: "symbols", "letters", "numbers",
"hanging", "format", etc.</t>
<t>
<list style="symbols">
<t>First bullet</t>
<t>Second bullet</t>
</list>
</t>
-->
<!--
<figure anchor="reference" title="Figure">
<artwork align="center">
<![CDATA[
ASCII artwork goes here...
]]>
</artwork>
</figure>
-->
<section anchor="sect1" title="Introduction">
<t>This document provides Smart Grid designers with advice on how to
best "profile" the Internet Protocol Suite (IPS) for use in Smart Grids.
It provides an overview of the IPS and the key infrastructure protocols
that are critical in integrating Smart Grid devices into an IP-based
infrastructure.</t>
<t>In the words of the Wikipedia <xref target="SmartGrid"></xref>, <list
style="empty">
<t>A Smart Grid is a form of electricity network utilizing digital
technology. A Smart Grid delivers electricity from suppliers to
consumers using two-way digital communications to control appliances
at consumers' homes; this saves energy, reduces costs and increases
reliability and transparency. It overlays the ordinary electrical
Grid with an information and net metering system, that includes
smart meters. Smart Grids are being promoted by many governments as
a way of addressing energy independence, global warming and
emergency resilience issues.</t>
<t>A Smart Grid is made possible by applying sensing, measurement
and control devices with two-way communications to electricity
production, transmission, distribution and consumption parts of the
power Grid that communicate information about Grid condition to
system users, operators and automated devices, making it possible to
dynamically respond to changes in Grid condition.</t>
<t>A Smart Grid includes an intelligent monitoring system that keeps
track of all electricity flowing in the system. It also has the
capability of integrating renewable electricity such as solar and
wind. When power is least expensive the user can allow the smart
Grid to turn on selected home appliances such as washing machines or
factory processes that can run at arbitrary hours. At peak times it
could turn off selected appliances to reduce demand.</t>
<t>Other names for a Smart Grid (or for similar proposals) include
smart electric or power Grid, intelligent Grid (or intelliGrid),
futureGrid, and the more modern interGrid and intraGrid.</t>
</list></t>
<t>That description focuses on the implications of Smart Grid technology
in the home of a consumer. In fact, data communications technologies of
various kinds are used throughout the Grid, to monitor and maintain
power generation, transmission, and distribution, as well as the
operations and management of the Grid. One can view the Smart Grid as a
collection of interconnected computer networks that connects and serves
the needs of public and private electrical utilities and their
customers.</t>
<t>At this writing, there is no single document that can be described as
comprising an internationally agreed standard for the Smart Grid; that
is in part the issue being addressed in its development. The nearest
approximations are probably the Smart Grid Interoperability Panel's
<xref target="Model"> Conceptual Model</xref> and documents comprising
<xref target="IEC61850"></xref>.</t>
<t>The Internet Protocol Suite (IPS) provides options for numerous
architectural components. For example, the IPS provides several choices
for the traditional transport function between two systems: the
Transmission Control Protocol (TCP) <xref target="RFC0793"></xref>, the
Stream Control Transmission Protocol (SCTP) <xref
target="RFC4960"></xref>, and the Datagram Congestion Control Protocol
(DCCP) <xref target="RFC4340"></xref>. Another option is to select an
encapsulation such as the User Datagram Protocol (UDP) <xref
target="RFC0768"></xref> which essentially allows an application to
implement its own transport service. In practice, a designer will pick a
transport protocol which is appropriate to the problem being solved.</t>
<t>The IPS is standardized by the Internet Engineering Task Force
(IETF). IETF protocols are documented in the Request for Comment (RFC)
series. Several RFCs have been written describing how the IPS should be
implemented. These include: <list style="symbols">
<t><xref target="RFC1122">Requirements for Internet Hosts -
Communication Layers</xref>,</t>
<t><xref target="RFC1123">Requirements for Internet Hosts -
Application and Support</xref>,</t>
<t><xref target="RFC1812">Requirements for IP Version 4
Routers</xref>, and</t>
<t><xref target="RFC4294">IPv6 Node Requirements</xref>,</t>
</list></t>
<t>At this writing, RFC 4294 is in the process of being updated, in
<xref target="I-D.ietf-6man-node-req-bis"></xref>.</t>
<t>This document is intended to provide Smart Grid architects and
designers with a compendium of relevant RFCs (and to some extent,
Internet Drafts), and is organized as an annotated list of RFCs. To that
end, the remainder of this document is organized as follows: <list
style="symbols">
<t><xref target="sect2"></xref> describes the Internet Architecture
and its protocol suite.</t>
<t><xref target="sect3"></xref> outlines a set of protocols that may
be useful in Smart Grid deployment. It is not exhaustive.</t>
<t>Finally, <xref target="network"></xref> provides an overview of
the business architecture embodied in the design and deployment of
the IPS.</t>
</list></t>
</section>
<section anchor="sect2" title="The Internet Protocol Suite">
<t>Before enumerating the list of Internet protocols relevant to Smart
Grid, we discuss the layered architecture of the IPS, the functions of
the various layers, and their associated protocols.</t>
<section anchor="sect2.1" title="Internet Protocol Layers">
<t>While Internet architecture uses the definitions and language
similar to language used by the ISO Open System Interconnect Reference
(ISO-OSI) Model (<xref target="iso-osi"></xref>), it actually predates
that model. As a result, there is some skew in terminology. For
example, the ISO-OSI model uses "end system" while the Internet
architecture uses "host". Similarly, an "intermediate system" in the
ISO-OSI model is called an "internet gateway" or "router" in Internet
parlance. Notwithstanding these differences, the fundamental concepts
are largely the same.</t>
<figure anchor="iso-osi" title="The ISO OSI Reference Model">
<artwork align="center"><![CDATA[
+--------------------+
| Application Layer |
+--------------------+
| Presentation Layer |
+--------------------+
| Session Layer |
+--------------------+
| Transport layer |
+--------------------+
| Network Layer |
+--------------------+
| Data Link Layer |
+--------------------+
| Physical Layer |
+--------------------+
]]></artwork>
</figure>
<t>The structure of the Internet reference model is shown in <xref
target="irm"></xref>.</t>
<figure anchor="irm" title="The Internet Reference Model">
<artwork align="center"><![CDATA[
+---------------------------------+
|Application |
| +---------------------------+ |
| | Application Protocol | |
| +----------+----------------+ |
| | Encoding | Session Control| |
| +----------+----------------+ |
+---------------------------------+
|Transport |
| +---------------------------+ |
| | Transport layer | |
| +---------------------------+ |
+---------------------------------+
|Network |
| +---------------------------+ |
| | Internet Protocol | |
| +---------------------------+ |
| | Lower network layers | |
| +---------------------------+ |
+---------------------------------+
|Media layers |
| +---------------------------+ |
| | Data Link Layer | |
| +---------------------------+ |
| | Physical Layer | |
| +---------------------------+ |
+---------------------------------+
]]></artwork>
</figure>
<section anchor="sect2.1.1" title="Application">
<t>In the Internet model, the Application, Presentation, and Session
layers are compressed into a single entity called "the application".
For example, the Simple Network Management Protocol (SNMP) <xref
target="RFC3411"></xref> describes an application that encodes its
data in an ASN.1 profile and engages in a session to manage a
network element. The point here is that in the Internet the
distinction between these layers exists but is not highlighted.
Further, note that in <xref target="irm"></xref> these functions are
not necessarily cleanly layered: the fact that an application
protocol encodes its data in some way and that it manages sessions
in some way doesn't imply a hierarchy between those processes.
Rather, the application views encoding, session management, and a
variety of other services as a tool set that it uses while doing its
work.</t>
</section>
<section anchor="sect2.1.2" title="Transport">
<t>The term "transport" is perhaps among the most confusing concepts
in the communication architecture, to a large extent because people
with various backgrounds use it to refer to "the layer below that
which I am interested in, which gets my data to my peer". For
example, optical network engineers refer to optical fiber and
associated electronics as "the transport", while web designers refer
to the Hypertext Transfer Protocol (HTTP) <xref
target="RFC2616"></xref> (an application layer protocol) as "the
transport".</t>
<t>In the Internet protocol stack, the "transport" is the lowest
protocol layer that travels end-to-end unmodified, and is
responsible for end-to-end data delivery services. In the Internet
the transport layer is the layer above the network layer. Transport
layer protocols have a single minimum requirement: the ability to
multiplex several applications on one IP address. <xref
target="RFC0768">UDP</xref>, <xref target="RFC0793">TCP</xref>,
<xref target="RFC4340">DCCP</xref>, <xref
target="RFC4960">SCTP</xref>, and <xref target="RFC5740">NORM</xref>
each accomplish this using a pair of port numbers, one for the
sender and one for the receiver. A port number identifies an
application instance, which might be a general "listener" that peers
or clients may open sessions with, or a specific correspondent with
such a "listener". The session identification in an IP datagram is
often called the "five-tuple", and consists of the source and
destination IP addresses, the source and destination ports, and an
identifier for the transport protocol in use.</t>
<t>In addition, the responsibilities of a specific transport layer
protocol typically include the delivery of data (either as a stream
of messages or a stream of bytes) in a stated sequence with stated
expectations regarding delivery rate and loss. For example, TCP will
reduce its rate in response to loss, as a congestion control
trigger, while DCCP accepts some level of loss if necessary to
maintain timeliness.</t>
</section>
<section anchor="sect2.1.3" title="Network">
<t>The main function of the network layer is to identify a remote
destination and deliver data to it. In connection-oriented networks
such as Multi-protocol Label Switching (MPLS) <xref
target="RFC3031"></xref> or Asynchronous Transfer Mode (ATM), a path
is set up once, and data is delivered through it. In connectionless
networks such as Ethernet and IP, data is delivered as datagrams.
Each datagram contains both the source and destination network layer
addresses, and the network is responsible for delivering it. In the
Internet Protocol Suite, the Internet Protocol is the network that
runs end to end. It may be encapsulated over other LAN and WAN
technologies, including both IP networks and networks of other
types.</t>
<section anchor="sect2.1.3.1" title="Internet Protocol">
<t>IPv4 and IPv6, each of which is called the Internet Protocol,
are connectionless ("datagram") architectures. They are designed
as common elements that interconnect network elements across a
network of lower layer networks. In addition to the basic service
of identifying a datagram's source and destination, they offer
services to fragment and reassemble datagrams when necessary,
assist in diagnosis of network failures, and carry additional
information necessary in special cases.</t>
<t>The Internet layer provides a uniform network abstraction
network that hides the differences between various network
technologies. This is the layer that allows diverse networks such
as Ethernet, 802.15.4, etc. to be combined into a uniform IP
network. New network technologies can be introduced into the IP
Protocol Suite by defining how IP is carried over those
technologies, leaving the other layers of the IPS and applications
that use those protocol unchanged.</t>
</section>
<section anchor="sect2.1.3.2" title="Lower layer networks">
<t>The network layer can be recursively subdivided as needed. This
may be accomplished by tunneling, in which an IP datagram is
encapsulated in another IP header for delivery to a decapsulator.
IP is frequently carried in Virtual Private Networks (VPNs) across
the public Internet using tunneling technologies such as the
Tunnel mode of IPsec, IP-in-IP, and Generic Route Encapsulation
(GRE) <xref target="RFC2784"></xref>. In addition, IP is also
frequently carried in circuit networks such as MPLS <xref
target="RFC4364"></xref>, GMPLS, and ATM. Finally, IP is also
carried over wireless networks (IEEE 802.11, 802.15.4, or 802.16)
and switched Ethernet (IEEE 802.3) networks.</t>
</section>
</section>
<section anchor="sect2.1.4" title="Media layers: Physical and Link">
<t>At the lowest layer of the IP architecture, data is encoded in
messages and transmitted over the physical media. While the IETF
specifies algorithms for carrying IPv4 and IPv6 various media types,
it rarely actually defines the media - it happily uses
specifications from IEEE, ITU, and other sources.</t>
</section>
</section>
<section anchor="sect2.2" title="Security Issues">
<t>While it is popular to complain about the security of the Internet,
it is important to distinguish between attacks on protocols and
attacks on user (e.g., phishing). Attacks on users are largely
independent of protocol details, reflecting interface design issues or
user education problems, and are out of scope for this document.
Security problems with Internet protocols are in scope, of course, and
can often be mitigated using existing security features already
specified for the protocol, or by leveraging the security services
offered by other IETF protocols. See the <xref
target="I-D.ietf-tcpm-tcp-security">Security Assessment of the
Transmission Control Protocol (TCP)</xref> and the <xref
target="I-D.ietf-opsec-ip-security">Security Assessment of the
Internet Protocol version 4</xref> for more information on TCP and
IPv4 issues, respectively.</t>
<t>These solutions do, however, need to get deployed as well. The road
to widespread deployment can sometimes be painful since often multiple
stakeholders need to take actions. Experience has shown that this
takes some time, and very often only happens when the incentives are
high enough in relation to the costs.</t>
<t>Furthermore, it is important to stress that available standards are
important but the range of security problems is larger than a missing
standard; many security problems are the result of implementation bugs
and the result of certain deployment choices. While these are outside
the realm of standards development, they play an important role in the
security of the overall system. Security has to be integrated into the
entire process.</t>
<t>The IETF takes security seriously in the design of their protocols
and architectures; every IETF specification has to have a security
consideration section to document the offered security threats and
countermeasures. RFC 3522 <xref target="RFC3522"></xref> provides
recommendations writing such a security consideration section. It also
describes the classical Internet security threat model and lists
common security goals.</t>
<t>In a nutshell, security has to be integrated into every protocol,
protocol extension, and consequently, every layer of the protocol
stack to be useful. We illustrate this also throughout this document
with references to further security discussions. Our experience has
shown that dealing with it as an afterthought does not lead to the
desired outcome.</t>
<t>The discussion of security threats and available security
mechanisms aims to illustrate some of the design aspects that commonly
appear.</t>
<section anchor="sect2.2.1"
title="Physical and Data Link Layer Security">
<t>At the physical and data link layers, threats generally center on
physical attacks on the network - the effects of backhoes,
deterioration of physical media, and various kinds of environmental
noise. Radio-based networks are subject to signal fade due to
distance, interference, and environmental factors; it is widely
noted that IEEE 802.15.4 networks frequently place a metal ground
plate between the meter and the device that manages it. Fiber was at
one time deployed because it was believed to be untrappable; we have
since learned to tap it by bending the fiber and collecting
incidental light, and we have learned about backhoes. As a result,
some installations encase fiber optic cable in a pressurized sheath,
both to quickly identify the location of a cut and to make it more
difficult to tap.</t>
<t>While there are protocol behaviors that can detect certain
classes of physical faults, such as keep-alive exchanges, physical
security is generally not considered to be a protocol problem.</t>
<t>For wireless transmission technologies, eavesdropping on the
transmitted frames is also typically a concern. Additionally, those
operating networks may want to ensure to restrict access to their
infrastructure to those who are authenticated and authorized
(typically called 'network access authentication'). This procedure
is often offered by security primitives at the data link layer.</t>
</section>
<section anchor="sect2.2.2"
title="Network, Transport, and Application Layer Security">
<t>At the network, transport, and application layers, it is common
to demand a few basic security requirements, commonly referred to as
CIA (Confidentiality, Integrity, and Availability):<list
style="numbers">
<t>Confidentiality: Protect the transmitted data from
unauthorized disclosure (i.e., keep eavesdroppers from learning
what was transmitted). For example, for trust in e-commerce
applications credit card transactions are exchanged encrypted
between the Web browser and a Web server.</t>
<t>Integrity: Protect against unauthorized changes to exchanges,
including both intentional change or destruction and accidental
change or loss, by ensuring that changes to exchanges are
detectable. It has two parts: one for the data and one for the
peers. <list style="symbols">
<t>Peers need to verify that information that appears to be
from a trusted peer is really from that peer. This is
typically called 'data origin authentication'.</t>
<t>Peers need to validate that the content of the data
exchanged is unmodified. The term typically used for this
property is data integrity.</t>
</list></t>
<t>Availability: Ensure that the resource is accessible by
mitigating of denial of service attacks.</t>
</list></t>
<t>To this we add authenticity, which requires that the
communicating peers prove that they are in fact who they say they
are to each other (i.e., mutual authentication). This generally
means knowing "who" the peer is, and that they demonstrate the
possession of a "secret" as part of the security protocol
interaction.</t>
<t>The following three examples aim to illustrate these security
requirements.</t>
<t>One common attack against a TCP session is to bombard the session
with reset messages. Other attacks against TCP include the "SYN
flooding" attack, in which an attacker attempts to exhaust the
memory of the target by creating TCP state. In particular, the
attacker attempts to exhaust the target's memory by opening a large
number of unique TCP connections, each of which is represented by a
Transmission Control Block (TCB). The attack is successful if the
attacker can cause the target to fill its memory with TCBs.</t>
<t>A number of mechanisms have been developed to deal with these
types of denial of service attacks. One, SYN Cookies, delays state
establishment on the server side to a later phase in the protocol
exchange. Another mechanism, specifically targeting the reset attack
cited above, provides authentication services in TCP itself to
ensure that fake resets are rejected.</t>
<t>Another approach would be to offer security protection already at
a lower layer, such as IPsec (see <xref target="sect3.1.2"></xref>)
or TLS (see <xref target="sect3.1.3"></xref>), so that a host can
identify legitimate messages and discard the others, thus mitigating
any damage that may have been caused by the attack.</t>
<t>Another common attack involves unauthorized access to resources.
For example, an unauthorized party might try to attach to a network.
To protect against such an attack, an Internet Service Provider
(ISP) typically requires network access authentication of new hosts
demanding access to the network and to the Internet prior to
offering access. This exchange typically requires authentication of
that entity and a check in the ISPs back-end database to determine
whether corresponding subscriber records exist and still valid (e.g.
active subscription and sufficient credits).</t>
<t>From the discussion above, establishing a secure communication
channel is clearly an important concept frequently used to mitigate
a range of attacks. Unfortunately, focusing only on channel security
may not be enough for a given task. Threat models have evolved and
even some of the communication endpoints cannot be considered fully
trustworthy, i.e. even trusted peers may act maliciously.</t>
<t>Furthermore, many protocols are more sophisticated in their
protocol interaction and involve more than two parties in the
protocol exchange. Many of the application layer protocols, such as
email, instant messaging, voice over IP, and presence based
applications, fall into this category. With this class of protocols
in addition to secure channels between two parties also security
between non-neighboring communication partners need to be
considered. A detailed treatment of the security threats and
requirements of these multi-party protocols is beyond this
specification but the interested reader is referred to the
above-mentioned examples for an illustration of what technical
mechanisms have been investigated and proposed in the past.</t>
</section>
</section>
<section anchor="sect2.3" title="Network Infrastructure">
<t>While the following protocols are not critical to the design of a
specific system, they are important to running a network, and as such
are surveyed here.</t>
<section anchor="sect2.3.1" title="Domain Name System (DNS)">
<t>The DNS' main function is translating names to numeric IP
addresses. While this is not critical to running a network, certain
functions are made a lot easier if numeric addresses can be replaced
with mnemonic names. This facilitates renumbering of networks and
generally improves the manageability and serviceability of the
network. DNS has a set of security extensions called DNSSEC, which
can be used to provide strong cryptographic authentication to the
DNS. DNS and DNSSEC are discussed further in <xref
target="dns1"></xref>.</t>
</section>
<section anchor="sect2.3.2" title="Network Management">
<t>Network management has proven to be a difficult problem. As such,
various solutions have been proposed, implemented, and deployed.
Each solution has its proponents, all of whom have solid arguments
for their viewpoints. The IETF has two major network management
solutions for device operation: SNMP, which is ASN.1-encoded and is
primarily used for monitoring of system variables, and NetConf <xref
target="RFC4741"></xref>, which is XML-encoded and primarily used
for device configuration.</t>
<t>Another aspect of network management is the initial provisioning
and configuration of hosts, which is discussed in <xref
target="dhcp"></xref>. Note that Smart Grid deployments may require
identity authentication and authorization (as well as other
provisioning and configuration) that may not be within the scope of
either DHCP or Neighbor Discovery. While the IP Protocol Suite has
limited support for secure provisioning and configuration, these
problems have been solved using IP protocols in specifications such
as <xref target="SP-MULPIv3.0">DOCSIS 3.0</xref>.</t>
</section>
</section>
</section>
<section anchor="sect3" title="Specific protocols">
<t>In this section, having briefly laid out the IP architecture and some
of the problems that the architecture tries to address, we introduce
specific protocols that might be appropriate to various Smart Grid use
cases. Use cases should be analyzed along with privacy, Authentication,
Authorization, and Accounting (AAA), transport and network solution
dimensions. The following sections provide guidance for such
analysis.</t>
<section anchor="sect3.1" title="Security Toolbox">
<t>As noted, a key consideration in security solutions is a good
threat analysis coupled with appropriate mitigation strategies at each
layer. The IETF has over time developed a number of building blocks
for security based on the observation that protocols often demand
similar security services. The following sub-sections outline a few of
those commonly used security building blocks. Re-using them offers
several advantages, such as availability of open source code,
experience with existing systems, a number of extensions that have
been developed, and the confidence that the listed technologies have
been reviewed and analyzed by a number of security experts.</t>
<t>It is important to highlight that in addition to the mentioned
security tools every protocol often comes with additional, often
unique security considerations that are unique to the specific domain
that protocol operates in. Many protocols include features
specifically designed to mitigate these protocol-specific risks. In
other cases, the security considerations will identify
security-relevant services that are required from other network layers
to achieve appropriate levels of security.</t>
<section anchor="sect3.1.1"
title="Authentication, Authorization, and Accounting (AAA)">
<t>While the term AAA sounds generic and applicable to all sorts of
security protocols it has been, in the IETF, used in relation to
network access authentication and is associated with the RADIUS
(<xref target="RFC2865"></xref>) and the Diameter protocol (<xref
target="RFC3588"></xref>, <xref
target="I-D.ietf-dime-rfc3588bis"></xref>) in particular.</t>
<t>The authentication procedure for network access aims to deal with
the task of verifying that a peer is authenticated and authorized
prior to accessing a particular resource (often connectivity to the
Internet). Typically, the authentication architecture for network
access consists of the following building blocks: the Extensible
Authentication Protocol (EAP <xref target="RFC4017"></xref>) as a
container to encapsulate EAP methods, an EAP Method (as a specific
way to perform cryptographic authentication and key exchange, such
as RFC 5216 <xref target="RFC5216"></xref>, RFC 5433 <xref
target="RFC5433"></xref>), a protocol that carries EAP payloads
between the end host and a server side entity (such as a network
access server), and a way to carry EAP payloads to back-end server
infrastructure (potentially in a cross-domain scenario) to provide
authorization and accounting functionality. The latter part is
provided by RADIUS and Diameter. To carry EAP payloads between the
end host and a network access server different mechanisms have been
standardized, such as PANA <xref target="RFC5191"></xref> and <xref
target="IEEE802.1X">IEEE 802.1X</xref> . For access to remote
networks, such as enterprise networks, the ability to utilize EAP
within IKEv2 <xref target="RFC5996"></xref> has also been
developed.</t>
<t>More recently, the same architecture with EAP and RADIUS/Diameter
is being re-used for application layer protocols. More details about
this architectural variant can be found in <xref
target="I-D.lear-abfab-arch"></xref>.</t>
</section>
<section anchor="sect3.1.2" title="Network Layer Security">
<t>IP security, as described in <xref target="RFC4301"></xref>,
addresses security at the IP layer, provided through the use of a
combination of cryptographic and protocol security mechanisms. It
offers a set of security services for traffic at the IP layer, in
both the IPv4 and IPv6 environment. The set of security services
offered includes access control, connectionless integrity, data
origin authentication, detection and rejection of replays (a form of
partial sequence integrity), confidentiality (via encryption), and
limited traffic flow confidentiality. These services are provided at
the IP layer, offering protection in a standard fashion for all
protocols that may be carried over IP (including IP itself).</t>
<t>The architecture foresees a split between the rather
time-consuming (a) authentication and key exchange protocol step
that also establishes a security association; a data structure with
keying material and security parameters and (b) the actual data
traffic protection.</t>
<t>For the former step the Internet Key Exchange protocol version 2
(IKEv2 <xref target="RFC5996"></xref>) is the most recent edition of
the standardized protocol. IKE negotiates each of the cryptographic
algorithms that will be used to protect the data independently,
somewhat like selecting items a la carte.</t>
<t>For the actual data protection two types of protocols have
historically been used, namely the IP Authentication Header (AH)
<xref target="RFC4302"></xref> and the Encapsulating Security
Payload (ESP) <xref target="RFC4303"></xref>. The two differ in the
security services they offer; the most important distinction is that
ESP offers confidentiality protection while AH does not. Since ESP
can also provide authentication services, most recent protocol
development making use of IPsec only specify use of ESP and do not
use AH.</t>
<t>In addition to these base line protocol mechanisms a number of
extensions have been developed for IKEv2 (e.g., an extension to
perform EAP-only authentication <xref target="RFC5998"></xref>) and
since the architecture supports flexible treatment of cryptographic
algorithms a number of them have been specified (e.g., <xref
target="RFC4307"></xref> for IKEv2, and <xref
target="RFC4835"></xref> for AH and ESP).</t>
</section>
<section anchor="sect3.1.3" title="Transport Layer Security">
<t>Transport Layer Security v1.2 <xref target="RFC5246"></xref> are
security services that protect data above the transport layer. The
protocol allows client/server applications to communicate in a way
that is designed to prevent eavesdropping, tampering, or message
forgery. TLS is application protocol independent.</t>
<t>TLS is composed of two layers: the TLS Record protocol and the
TLS Handshake protocol. The TLS Record protocol provides connection
security that has two basic properties: (a) confidentiality
protection and (b) integrity protection.</t>
<t>The TLS Handshake protocol allows the server and client to
authenticate each other and to negotiate an encryption algorithm and
cryptographic keys before the application protocol transmits or
receives its first byte of data. The negotiated parameters and the
derived keying material is then used by the TLS Record protocol to
perform its job.</t>
<t>Unlike IKEv2/IPsec TLS negotiates these cryptographic parameters
in suites, so-called cipher suites. Examples of cipher suites that
can be negotiated with TLS include <xref target="RFC4492">Elliptic
Curve Cryptography (ECC) </xref><xref target="RFC5289"></xref><xref
target="I-D.mcgrew-tls-aes-ccm-ecc"></xref>, <xref
target="RFC5932">Camellia</xref>, and the <xref
target="RFC5430">Suite B Profile</xref>. <xref
target="IEC62351-3"></xref> outlines the use of different TLS Cipher
Suites for use in the Smart Grid. The basic cryptographic mechanisms
for ECC have been documented in <xref target="RFC6090"></xref>.</t>
<t>TLS must run over a reliable transport channel -- typically TCP.
In order to offer the same security services for unreliable datagram
traffic, such as UDP, the Datagram Transport Layer Security (DTLS
<xref target="RFC4347"></xref> <xref
target="I-D.ietf-tls-rfc4347-bis"></xref>) was developed.</t>
</section>
<section anchor="sect3.1.4" title="Application Layer Security">
<t>In certain cases the application layer independent security
mechanisms described in the previous sub-sections are not sufficient
to deal with all the identified threats. For this purpose, a number
of security primitives are additionally available at the application
layer where the semantic of the application can be considered.</t>
<t>We will focus with our description on a few mechanisms that are
commonly used throughout the Internet.</t>
<t>Cryptographic Message Syntax (CMS <xref target="RFC5652"></xref>)
is an encapsulation syntax to sign, digest, authenticate, or encrypt
arbitrary message content. It also allows arbitrary attributes, such
as signing time, to be signed along with the message content, and it
provides for other attributes such as countersignatures to be
associated with a signature. The CMS can support a variety of
architectures for certificate-based key management, such as the one
defined by the PKIX (Public Key Infrastructure using X.509) working
group <xref target="RFC5280"></xref>. CMS has been leveraged to
supply security services in a variety of protocols, including secure
email <xref target="RFC5751"></xref>, key management <xref
target="RFC5958"></xref> and <xref target="RFC6031"></xref>, and
firmware updates <xref target="RFC4108"></xref>.</t>
<t>Related work includes the use of digital signatures on
XML-encoded documents, which has been jointly standardized by W3C
and the IETF <xref target="RFC3275"></xref>. Digitally signed XML is
a good choice where applications natively support XML encoded data,
such as XMPP.</t>
<t>More recently, the work on delegated authentication and
authorization often demanded by Web applications have been developed
with the Open Web Authentication (OAuth) protocol <xref
target="RFC5849"></xref>, <xref target="I-D.ietf-oauth-v2"></xref>.
OAuth is used by third-party applications to gain access to
protected resources (such as energy consumption information about a
specific household), without having the resource owner to shares its
long-term credentials with that third-party. In OAuth, the
third-party application requests access to resources controlled by
the resource owner and hosted by the resource server, and is issued
a different set of credentials than those of the resource owner.
More specifically, the third-party applications obtains an access
token, a string denoting a specific scope, duration, and other
access attributes, during the OAuth protocol exchange securely gain
access to the protected resource with the consent of the resource
owner.</t>
</section>
<section anchor="sect3.1.5" title="Secure Shell">
<t>The Secure Shell (SSH) protocol <xref target="RFC4253"></xref>
has been widely used by administrators and others for secure remote
login, but is also usable for secure tunelling. More recently,
protocols have chosen to layer on top of SSH in for transport
security services, for example the netconf network management
protocol (see <xref target="netconf"></xref>) uses SSH as its main
communications security protocol.</t>
</section>
<section anchor="sect3.1.6" title="Key Management Infrastructures">
<t>All the above security protocols depend on cryptography for
security, and hence require some form of key management. Most IETF
protocols at least nominally require some scalable form of key
management to be defined as mandatory to implement, indeed the lack
of such key management features has in the past been a reason to
delay approval of protocols. There are two generic key management
schemes that are widely used by other Internet protocols, PKIX and
Kerberos, each of which is briefly described below. </t>
<section anchor="sect3.1.6.1" title="PKIX">
<t>Public Key Infrastructure (PKI) refers to the kind of key
management that is based on certification authorities (CAs)
issuing public key certificates for other key holders. By chaining
from a trust anchor (a locally trusted copy of a CA public key),
down to the public key of some protocol peer, PKI allows for
secure binding between keys and protocol-specific names, such as
email addresses, and hence enables security services such as data
and peer authentication, data integrity and confidentiality
(encryption).</t>
<t>The main Internet standard for PKI is <xref
target="RFC5280"></xref> which is a profile of the X.509 public
key certificate format. There are a range of private and
commercial CAs operating today providing the ability to manage and
securely distribute keys for all protocols that use public key
certificates, e.g. TLS, S/MIME. In addition to the profile
standard, the PKIX working group has defined a number of
management protocols (e.g. <xref target="RFC5272"></xref>, <xref
target="RFC4210"></xref>) as well as protocols for handling
revocation of public key certificates such as the Online
Certificate Status Protocol (OCSP). <xref
target="RFC2560"></xref></t>
<t>PKI is generally perceived to better handle use-cases spanning
multiple independent domains when compared to Kerberos.</t>
</section>
<section anchor="sect3.1.6.2" title="Kerberos">
<t>The Kerberos network Authentication System <xref
target="RFC4120"></xref> is commonly used within organizations to
centralize authentication, authorization and policy in one place.
Kerberos natively supports usernames and passwords as the basis of
authentication. With Pkinit <xref target="RFC4556"></xref>,
Kerberos supports certificate or public-key-based authentication.
This may provide an advantage by concentrating policy about
certificate validation and mapping of certificates to user
accounts in one place. Through the GSS-API <xref
target="RFC1964"></xref> <xref target="RFC2743"></xref> <xref
target="RFC4121"></xref>, Kerberos can be used to manage
authentication for most applications. While Kerberos works best
within organizations and enterprises, it does have facilities that
permit authentication to be shared between administrative
domains.</t>
</section>
</section>
</section>
<section anchor="sect3.2" title="Network Layer">
<t>The IPS specifies two network layer protocols: IPv4 and IPv6. The
following sections describe the IETF's coexistence and transition
mechanisms for IPv4 and IPv6.</t>
<t>Note that on 3 February 2011 the IANA's IPv4 free pool (the pool of
available, unallocated IPv4 addresses) was exhausted, and the RIR free
pools are expected to be exhausted during them coming year at most.
The IETF, the IANA, and the Regional Internet Registrars recommends
that new deployments use IPv6, and that IPv4 infrastructures are
supported via the mechanisms described in <xref
target="sect3.2.1"></xref>.</t>
<section anchor="sect3.2.1" title="IPv4/IPv6 Coexistence Advice">
<t>The IETF has specified a variety of mechanisms designed to
facilitate IPv4/IPv6 coexistence. The IETF actually recommends
relatively few of them: the current advice to network operators is
found in <xref
target="I-D.arkko-ipv6-transition-guidelines">Guidelines for Using
IPv6 Transition Mechanisms</xref>. The thoughts in that document are
replicated here.</t>
<section anchor="sect3.2.1.1" title="Dual Stack Coexistence">
<t>The simplest coexistence approach is to <list style="symbols">
<t>provide a network that routes both IPv4 and IPv6,</t>
<t>ensure that servers and their applications similarly
support both protocols, and</t>
<t>require that all new systems and applications purchased or
upgraded support both protocols.</t>
</list></t>
<t>The net result is that over time all systems become protocol
agnostic, and that eventually maintenance of IPv4 support becomes
a business decision. This approach is described in the <xref
target="RFC4213">Basic Transition Mechanisms for IPv6 Hosts and
Routers</xref>.</t>
</section>
<section anchor="sect3.2.1.2" title="Tunneling Mechanism">
<t>In those places in the network that support only IPv4 the
simplest and most reliable approach is to provide virtual
connectivity using tunnels or encapsulations. Early in the IPv6
deployment, this was often done using static tunnels. A more
dynamic approach is documented in <xref target="RFC5569">IPv6
Rapid Deployment on IPv4 Infrastructures (6rd)</xref>.</t>
</section>
<section anchor="sect3.2.1.3"
title="Translation between IPv4 and IPv6 Networks">
<t>In those cases where an IPv4-only host would like to
communicate with an IPv6-only host (or vice versa), protocol
translation may be indicated. At first blush, protocol translation
may appear trivial; on deeper inspection, it turns out that
protocol translation can be complicated.</t>
<t>The most reliable approach to protocol translation is to
provide application layer proxies or gateways, which natively
enable application-to-application connections using both protocols
and can use whichever is appropriate. For example, a web proxy
might use both protocols and as a result enable an IPv4-only
system to run HTTP across on IPv6-only network or to a web server
that implements only IPv6. Since this approach is a service of a
protocol-agnostic server, it is not the subject of standardization
by the IETF.</t>
<t>For those applications in which network layer translation is
indicated, the IETF has designed a translation mechanism which is
described in the following documents: <list style="symbols">
<t><xref target="I-D.ietf-behave-v6v4-framework">Framework for
IPv4/IPv6 Translation</xref></t>
<t><xref target="RFC6052">IPv6 Addressing of IPv4/IPv6
Translators</xref></t>
<t><xref target="I-D.ietf-behave-dns64">DNS
extensions</xref></t>
<t><xref target="I-D.ietf-behave-v6v4-xlate">IP/ICMP
Translation Algorithm</xref></t>
<t><xref
target="I-D.ietf-behave-v6v4-xlate-stateful">Translation from
IPv6 Clients to IPv4 Servers</xref></t>
</list></t>
<t>As with IPv4/IPv4 Network Address Translation, translation
between IPv4 and IPv6 has limited real world applicability for an
application protocol which carry IP addresses in its payload and
expects those addresses to be meaningful to both client and
server. However, for those protocols that do not, protocol
translation can provide a useful network extension.</t>
<t>Network-based translation provides for two types of services:
stateless (and therefore scalable and load-sharable) translation
between IPv4 and IPv6 addresses that embed an IPv4 address in
them, and stateful translation similar to IPv4/IPv4 translation
between IPv4 addresses. The stateless mode is straightforward to
implement, but due to the embedding, requires IPv4 addresses to be
allocated to an otherwise IPv6-only network, and is primarily
useful for IPv4-accessible servers implemented in the IPv6
network. The stateful mode allows clients in the IPv6 network to
access servers in the IPv4 network, but does not provide such
service for IPv4 clients accessing IPv6 peers or servers with
general addresses; it has the advantage that it does not require
that a unique IPv4 address be embedded in the IPv6 address of
hosts using this mechanism.</t>
<t>Finally, note that some site networks are IPv6 only while some
transit networks are IPv4 only. In these cases, it may be
necessary to tunnel IPv6 over IPv4 or translate between IPv6 and
IPv4.</t>
</section>
</section>
<section anchor="ipv4" title="Internet Protocol Version 4">
<t><xref target="RFC0791">IPv4</xref> and the <xref
target="RFC0792">Internet Control Message Protocol</xref> comprise
the IPv4 network layer. IPv4 provides unreliable delivery of
datagrams.</t>
<t>IPv4 also provides for fragmentation and reassembly of long
datagrams for transmission through networks with small Maximum
Transmission Units (MTU). The MTU is the largest packet size that
can be delivered across the network. In addition, the IPS provides
the Internet Control Message Protocol (ICMP) <xref
target="RFC0792"></xref>, which is a separate protocol that enables
the network to report errors and other issues to hosts that
originate problematic datagrams.</t>
<t>IPv4 originally supported an experimental type of service field
that identified eight levels of operational precedence styled after
the requirements of military telephony, plus three and later four
bit flags that <xref target="RFC1195">OSI IS-IS for IPv4 (IS-IS)
</xref> and <xref target="RFC2328">OSPF Version 2</xref> interpreted
as control traffic; this control traffic is assured of not being
dropped when queued or upon receipt, even if other traffic is being
dropped.. These control bits turned out to be less useful than the
designers had hoped. They were replaced by the <xref
target="RFC2474">Differentiated Services Architecture</xref><xref
target="RFC2475"></xref>, which contains a six bit code point used
to select an algorithm (a "per-hop behavior") to be applied to the
datagram. The IETF has also produced a set of <xref
target="RFC4594">Configuration Guidelines for DiffServ Service
Classes</xref>, which describes a set of service classes that may be
useful to a network operator.</t>
<section title="IPv4 Address Allocation and Assignment">
<t>IPv4 addresses are administratively assigned, usually using
automated methods, and assigned using the <xref
target="RFC2131">Dynamic Host Configuration Protocol
(DHCP)</xref>. On most interface types, neighboring systems
identify each other's addresses using the <xref
target="RFC0826">Address Resolution Protocol (ARP)</xref>.</t>
</section>
<section title="IPv4 Unicast Routing">
<t>Routing for the IPv4 Internet is accomplished by routing
applications that exchange connectivity information and build
semi-static destination routing databases. If a datagram is
directed to a given destination address, the address is looked up
in the routing database, and the most specific ("longest") prefix
found that contains it is used to identify the next hop router, or
the end system it will be delivered to. This is not generally
implemented on hosts, although it can be; a host normally sends
datagrams to a router on its local network, and the router carries
out the intent.</t>
<t>IETF specified routing protocols include <xref
target="RFC2453">RIP Version 2</xref>, <xref target="RFC1195">OSI
IS-IS for IPv4</xref>, <xref target="RFC2328">OSPF Version
2</xref>, and <xref target="RFC4271">BGP-4</xref>. Active research
exists in mobile ad hoc routing and other routing paradigms; these
result in new protocols and modified forwarding paradigms.</t>
</section>
<section anchor="Multicast"
title="IPv4 Multicast Forwarding and Routing">
<t>IPv4 was originally specified as a unicast (point to point)
protocol, and was extended to support multicast in <xref
target="RFC1112"></xref>. This uses the <xref
target="RFC3376">Internet Group Management Protocol</xref><xref
target="RFC4604"></xref> to enable applications to join multicast
groups, and for most applications uses <xref
target="RFC4607">Source-Specific Multicast</xref> for routing and
delivery of multicast messages.</t>
<t>An experiment carried out in IPv4 that is not part of the core
Internet architecture but may be of interest in the Smart Grid is
the development of so-called "Reliable Multicast". This is
"so-called" because it is not "reliable" in the strict sense of
the word - it is perhaps better described as "enhanced
reliability". A best effort network by definition can lose
traffic, duplicate it, or reorder it, something as true for
multicast as for unicast. Research in "Reliable Multicast"
technology intends to improve the probability of delivery of
multicast traffic.</t>
<t>In that research, the IETF imposed <xref
target="RFC2357">guidelines</xref> on the research community
regarding what was desirable. Important results from that research
include a number of papers and several proprietary protocols
including some that have been used in support of business
operations. RFCs in the area include <xref target="RFC3453"> The
Use of Forward Error Correction (FEC) in Reliable Multicast
</xref>, the <xref target="RFC5740"> Negative-acknowledgment
(NACK)-Oriented Reliable Multicast (NORM) Protocol </xref>, and
the <xref target="RFC4410"> Selectively Reliable Multicast
Protocol (SRMP) </xref>.</t>
</section>
</section>
<section anchor="ipv6" title="Internet Protocol Version 6">
<t><xref target="RFC2460">IPv6</xref>, with the <xref
target="RFC4443">Internet Control Message Protocol "v6"</xref>,
constitutes the next generation protocol for the Internet. IPv6
provides for transmission of datagrams from source to destination
hosts, which are identified by fixed length addresses.</t>
<t>IPv6 also provides for fragmentation and reassembly of long
datagrams by the originating host, if necessary, for transmission
through "small packet" networks. ICMPv6, which is a separate
protocol implemented along with IPv6, enables the network to report
errors and other issues to hosts that originate problematic
datagrams.</t>
<t>IPv6 adopted the <xref target="RFC2474">Differentiated Services
Architecture</xref><xref target="RFC2475"></xref>, which contains a
six bit code point used to select an algorithm (a "per-hop
behavior") to be applied to the datagram.</t>
<t>The <xref target="RFC4919">IPv6 over Low-Power Wireless Personal
Area Networks</xref> RFC and the <xref
target="I-D.ietf-6lowpan-hc">Compression Format for IPv6 Datagrams
in 6LoWPAN Networks</xref> addresses IPv6 header compression and
subnet architecture in at least some sensor networks, and may be
appropriate to the Smart Grid Advanced Metering Infrastructure or
other sensor domains.</t>
<section title="IPv6 Address Allocation and Assignment">
<t>An <xref target="RFC4291">IPv6 Address</xref> may be
administratively assigned using <xref
target="RFC3315">DHCPv6</xref> in a manner similar to the way IPv4
addresses are. In addition, IPv6 addresses may also be
autoconfigured. Autoconfiguration enables various models of
network management which may be advantageous in different use
cases. Autoconfiguration procedures are defined in <xref
target="RFC4862"></xref> and <xref target="RFC4941"></xref>. IPv6
neighbors identify each other's addresses using either <xref
target="RFC4861">Neighbor Discovery (ND)</xref>. <xref
target="RFC3971">SEcure Neighbor Discovery (SEND)</xref> may be
used to secure these operations.</t>
</section>
<section title="IPv6 Routing">
<t>Routing for the IPv6 Internet is accomplished by routing
applications that exchange connectivity information and build
semi-static destination routing databases. If a datagram is
directed to a given destination address, the address is looked up
in the routing database, and the most specific ("longest") prefix
found that contains it is used to identify the next hop router, or
the end system it will be delivered to. Routing is not generally
implemented on hosts (although it can be); generally, a host sends
datagrams to a router on its local network, and the router carries
out the intent.</t>
<t>IETF specified routing protocols include <xref
target="RFC2080">RIP for IPv6</xref>, <xref target="RFC5308">IS-IS
for IPv6</xref>, <xref target="RFC5340">OSPF for IPv6</xref>, and
<xref target="RFC2545">BGP-4 for IPv6</xref>. Active research
exists in mobile ad hoc routing, routing in low power networks
(sensors and Smart Grids) and other routing paradigms; these
result in new protocols and modified forwarding paradigms.</t>
</section>
</section>
<section anchor="Routing" title="Routing for IPv4 and IPv6">
<t></t>
<section anchor="RIP" title="Routing Information Protocol">
<t>The prototypical routing protocol used in the Internet has
probably been the <xref target="RFC1058">Routing Information
Protocol</xref>. People that use it today tend to deploy <xref
target="RFC2080">RIPng for IPv6</xref> and <xref
target="RFC2453">RIP Version 2</xref>. Briefly, RIP is a distance
vector routing protocol that is based on a distributed variant of
the widely known Bellman-Ford algorithm. In distance vector
routing protocols, each router announces the contents of its route
table to neighboring routers, which integrate the results with
their route tables and re-announce them to others. It has been
characterized as "routing by rumor", and suffers many of the ills
we find in human gossip - propagating stale or incorrect
information in certain failure scenarios, and being in cases
unresponsive to changes in topology. <xref
target="RFC1058"></xref> provides guidance to algorithm designers
to mitigate these issues.</t>
</section>
<section anchor="OSPF" title="Open Shortest Path First">
<t>The Open Shortest Path First (OSPF) routing protocol is one of
the more widely used protocols in the Internet. OSPF is a based on
Dijkstra's well known shortest path first (SPF) algorithm. It is
implemented as <xref target="RFC2328">OSPF Version 2</xref> for
IPv4, <xref target="RFC5340">OSPF for IPv6</xref> for IPv6, and
the <xref target="RFC5838">Support of Address Families in
OSPFv3</xref> to enable <xref target="RFC5340"></xref> to route
both IPv4 and IPv6.</t>
<t>The advantage of any SPF-based protocol (i.e., OSPF and IS-IS)
is primarily that every router in the network constructs its view
of the network from first hand knowledge rather than the "gossip"
that distance vector protocols propagate. As such, the topology is
quickly and easily changed by simply announcing the change. The
disadvantage of SPF-based protocols is that each router must store
a first-person statement of the connectivity of each router in the
domain.</t>
</section>
<section anchor="ISIS"
title="ISO Intermediate System to Intermediate System">
<t>The Intermediate System to Intermediate System (IS-IS) routing
protocol is one of the more widely used protocols in the Internet.
IS-IS is also based on Dijkstra's SPF algorithm. It was originally
specified as ISO DP 10589 for the routing of CLNS, and extended
for <xref target="RFC1195">routing in TCP/IP and dual
environments</xref>, and more recently for <xref
target="RFC5308">routing of IPv6 </xref>.</t>
<t>As with OSPF, the positives of any SPF-based protocol and
specifically IS-IS are primarily that the network is described as
a lattice of routers with connectivity to subnets and isolated
hosts. It's topology is quickly and easily changed by simply
announcing the change, without the issues of "routing by rumor",
since every host within the routing domain has a first-person
statement of the connectivity of each router in the domain. The
negatives are a corollary: each router must store a first-person
statement of the connectivity of each router in the domain.</t>
</section>
<section anchor="BGP" title="Border Gateway Protocol">
<t>The <xref target="RFC4271">Border Gateway Protocol (BGP)
</xref> is widely used in the IPv4 Internet to exchange routes
between administrative entities - service providers, their peers,
their upstream networks, and their customers - while applying
specific policy. <xref target="RFC4760">Multi-protocol Extensions
</xref> to BGP allow BGP to carry <xref target="RFC2545">IPv6
Inter-Domain Routing</xref>, multicast reachability information,
and VPN information, among others.</t>
<t>Considerations that apply with BGP deal with the flexibility
and complexity of the policies that must be defined. Flexibility
is a good thing; in a network that is not run by professionals,
the complexity is burdensome.</t>
</section>
<section anchor="DYMO"
title="Dynamic MANET On-demand (DYMO) Routing">
<t>The Mobile Ad Hoc Working Group of the IETF developed, among
other protocols, the <xref target="RFC3561">Ad hoc On-Demand
Distance Vector (AODV) Routing</xref>. This protocol captured the
minds of some in the embedded devices industry, but experienced
issues in wireless networks such as 802.15.4 and 802.11's Ad Hoc
mode. As a result, it is in the process of being updated in the
<xref target="I-D.ietf-manet-dymo">Dynamic MANET On-demand (DYMO)
Routing</xref> protocol.</t>
<t>AODV and DYMO are essentially reactive routing protocols
designed for mobile ad hoc networks, and usable in other forms of
ad hoc networks. They provide connectivity between a device within
a distributed subnet and a few devices (including perhaps a
gateway or router to another subnet) without tracking connectivity
to other devices. In essence, routing is calculated and discovered
upon need, and a host or router need only maintain the routes that
currently work and are needed.</t>
</section>
<section anchor="OLSR" title="Optimized Link State Routing Protocol">
<t>The <xref target="RFC3626">Optimized Link State Routing
Protocol (OLSR)</xref> is a proactive routing protocol designed
for mobile ad hoc networks, and can be used in other forms of ad
hoc networks. It provides arbitrary connectivity between systems
within a distributed subnet. As with protocols designed for wired
networks, routing is calculated and maintained whenever changes
are detected, and maintained in each router's tables. The set of
nodes that operate as routers within the subnet, however, are
fairly fluid, and dependent on this instantaneous topology of the
subnet.</t>
</section>
<section anchor="RPL"
title="Routing for Low power and Lossy Networks">
<t>The IPv6 Routing Protocol for Low power and Lossy Networks
(RPL) <xref target="I-D.ietf-roll-rpl"></xref> is a reactive
routing protocol designed for use in resource constrained
networks. Requirements for resource constrained networks are
defined in <xref target="RFC5548"></xref>, <xref
target="RFC5673"></xref>, <xref target="RFC5826"></xref>, and
<xref target="RFC5867"></xref>.</t>
<t>Briefly, a constrained network is comprised of nodes that:</t>
<t><list style="symbols">
<t>Are built with limited processing power and memory, and
sometimes energy when operating on batteries.</t>
<t>Are interconnected through a low-data-rate network
interface and potentially vulnerable to communication
instability and low packet delivery rates.</t>
<t>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).</t>
</list></t>
</section>
</section>
<section title="IPv6 Multicast Forwarding and Routing">
<t>IPv6 specifies both unicast and multicast datagram exchange. This
uses the <xref target="RFC2710">Multicast Listener Discovery
Protocol (MLDv2)</xref> <xref target="RFC3590"></xref> <xref
target="RFC3810"></xref> <xref target="RFC4604"></xref> to enable
applications to join multicast groups, and for most applications
uses <xref target="RFC4607">Source-Specific Multicast</xref> for
routing and delivery of multicast messages.</t>
<t>The mechanisms experimentally developed for reliable multicast in
IPv4, discussed in <xref target="Multicast"></xref>, can be used in
IPv6 as well.</t>
<section anchor="PIM" title="Protocol-Independent Multicast Routing">
<t>A multicast routing protocol has two basic functions: Building
the multicast distribution tree and forwarding multicast traffic.
Multicast routing protocols generally contain a control plane for
building distribution trees, and a forwarding plane that uses the
distribution tree when forwarding multicast traffic.</t>
<t>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.</t>
<t>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 <xref target="RFC3973">Protocol Independent
Multicast - Dense Mode (PIM-DM): Protocol Specification
(Revised)</xref> and <xref target="RFC4601">Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)</xref> were designed for the ASM model.</t>
<t>Many modern multicast deployments use Source-Specific Multicast
(PIM-SSM) <xref target="RFC3569"></xref><xref
target="RFC4608"></xref>. In the SSM model, a host expresses
interest in a "channel", which is comprised of a source (S) and a
group (G). Distribution trees are rooted to the sending host
(called an "(S,G) tree"). Since only the source S can send on to
the group, SSM has inherent anti-jamming capability. In addition,
inter-domain multicast is simplified since it is the
responsibility of the receivers (rather than the network) to find
the (S,G) channel they are interested in receiving. This implies
that SSM requires some form of directory service so that receivers
can find the (S,G) channels.</t>
</section>
</section>
<section title="Adaptation to lower layer networks and link layer protocols">
<t>In general, the layered architecture of the Internet enables the
IPS to run over any appropriate layer two architecture. The ability
to change the link or physical layer without having to rethink the
network layer, transports, or applications has been a great benefit
in the Internet.</t>
<t>Examples of link layer adaptation technology include: <list
style="hanging">
<t hangText="Ethernet/IEEE 802.3:">IPv4 has run on each link
layer environment that uses the Ethernet header (which is to say
10 and 100 MBPS wired Ethernet, 1 and 10 GBPS wired Ethernet,
and the various versions of IEEE 802.11) using <xref
target="RFC0894"></xref>. IPv6 does the same using <xref
target="RFC2464"></xref>.</t>
<t hangText="PPP:">The IETF has defined a serial line protocol,
the <xref target="RFC1661">Point-to-Point Protocol (PPP)</xref>,
that uses HDLC (bit-synchronous or byte synchronous) framing.
The IPv4 adaptation specification is <xref
target="RFC1332"></xref>, and the IPv6 adaptation specification
is <xref target="RFC5072"></xref>. Current use of this protocol
is in traditional serial lines, authentication exchanges in DSL
networks using <xref target="RFC2516">PPP Over Ethernet
(PPPoE)</xref>, and in the Digital Signaling Hierarchy
(generally referred to as Packet-on-SONET/SDH) using <xref
target="RFC2615">PPP over SONET/SDH</xref>.</t>
<t hangText="IEEE 802.15.4:">The adaptation specification for
IPv6 transmission over IEEE 802.15.4 Networks is <xref
target="RFC4944"></xref>.</t>
</list></t>
<t>Numerous other adaptation specifications exist, including ATM,
Frame Relay, X.25, other standardized and proprietary LAN
technologies, and others.</t>
</section>
</section>
<section title="Transport Layer">
<t>This section outlines the functionality of UDP, TCP, SCTP, and
DCCP. UDP and TCP are best known and most widely used in the Internet
today, while SCTP and DCCP are newer protocols that built for specific
purposes. Other transport protocols can be built when required.</t>
<section title="User Datagram Protocol (UDP)">
<t>The <xref target="RFC0768">User Datagram Protocol</xref> and the
<xref target="RFC3828">Lightweight User Datagram Protocol</xref> are
properly not "transport" protocols in the sense of "a set of rules
governing the exchange or transmission of data electronically
between devices". They are labels that provide for multiplexing of
applications directly on the IP layer, with transport functionality
embedded in the application.</t>
<t>Many exchange designs have been built using UDP, and many of them
have not worked out. As a result, the use of UDP really should be
treated as designing a new transport. Advice on the use of UDP in
new applications can be found in <xref target="RFC5405">Unicast UDP
Usage Guidelines for Application Designers</xref>.</t>
<t><xref target="RFC5238">Datagram Transport Layer Security</xref>
can be used to prevent eavesdropping, tampering, or message forgery
for applications that run over UDP. Alternatively, UDP can run over
IPsec.</t>
</section>
<section title="Transmission Control Protocol (TCP)">
<t><xref target="RFC0793">TCP</xref> is the predominant transport
protocol in use in the Internet. It is "reliable", as the term is
used in protocol design: it delivers data to its peer and provides
acknowledgement to the sender, or it dies trying. It has extensions
for <xref target="RFC5681">Congestion Control</xref> and <xref
target="RFC3168">Explicit Congestion Notification</xref>.</t>
<t>The user interface for TCP is a byte stream interface - an
application using TCP might "write" to it several times only to have
the data compacted into a common segment and delivered as such to
its peer. For message-stream interfaces, ACSE/ROSE uses the <xref
target="RFC1006"> ISO Transport Service on TCP </xref><xref
target="RFC2126"></xref> in the application.</t>
<t><xref target="RFC5246">Transport Layer Security</xref> can be
used to prevent eavesdropping, tampering, or message forgery.
Alternatively, TCP can run over IPsec. Additionally, <xref
target="RFC4987"></xref> discusses mechanisms similar to SCTP and
DCCP's "cookie" approach that may be used to secure TCP sessions
against flooding attacks.</t>
<t>Finally, note that TCP has been the subject of ongoing research
and development since it was written. The <xref
target="RFC4614">Roadmap for TCP Specification Documents</xref>
captures this history, and is intended to be a guide to current and
future developers in the area.</t>
</section>
<section title="Stream Control Transmission Protocol (SCTP)">
<t><xref target="RFC4960">SCTP</xref> is a more recent reliable
transport protocol that can be imagined as a TCP-like context
containing multiple separate and independent message streams (unlike
TCP's byte streams). The design of SCTP includes appropriate
congestion avoidance behavior and resistance to flooding and
masquerade attacks. As it uses a message stream interface, it may
also be more appropriate for the ISO Transport Service than using
RFC 1006/2126 to turn TCP's octet streams into a message
interface.</t>
<t>SCTP offers several delivery options. The basic service is
sequential non-duplicated delivery of messages within a stream, for
each stream in use. Since streams are independent, one stream may
pause due to head of line blocking while another stream in the same
session continues to deliver data. In addition, SCTP provides a
mechanism for bypassing the sequenced delivery service. User
messages sent using this mechanism are delivered to the SCTP user as
soon as they are received.</t>
<t>SCTP implements a simple "cookie" mechanism intended to limit the
effectiveness of flooding attacks by mutual authentication. This
demonstrates that the application is connected to the same peer, but
does not identify the peer. Mechanisms also exist for <xref
target="RFC5061">Dynamic Address Reconfiguration</xref>, enabling
peers to change addresses during the session and yet retain
connectivity. <xref target="RFC3436">Transport Layer Security</xref>
can be used to prevent eavesdropping, tampering, or message forgery.
Alternatively, SCTP can run over IPsec.</t>
</section>
<section title="Datagram Congestion Control Protocol (DCCP)">
<t><xref target="RFC4340">DCCP</xref> is an "unreliable" transport
protocol (e.g., one that does not guarantee message delivery) that
provides bidirectional unicast connections of congestion-controlled
unreliable datagrams. DCCP is suitable for applications that
transfer fairly large amounts of data and that can benefit from
control over the tradeoff between timeliness and reliability.</t>
<t>DCCP implements a simple "cookie" mechanism intended to limit the
effectiveness of flooding attacks by mutual authentication. This
demonstrates that the application is connected to the same peer, but
does not identify the peer. <xref target="RFC5238">Datagram
Transport Layer Security</xref> can be used to prevent
eavesdropping, tampering, or message forgery. Alternatively, DCCP
can run over IPsec.</t>
</section>
</section>
<section anchor="infrastructure" title="Infrastructure">
<section anchor="dns1" title="Domain Name System">
<t>In order to facilitate network management and operations, the
Internet Community has defined the <xref target="RFC1034">Domain
Name System (DNS)</xref><xref target="RFC1035"></xref>. Names are
hierarchical: a name like example.com is found registered with a
.com registrar, and within the associated network other names like
baldur.cincinatti.example.com can be defined, with obvious
hierarchy. Security extensions, which allow a registry to sign the
records it contains and in so doing demonstrate their authenticity,
are defined by the DNS Security Extensions <xref
target="RFC4033"></xref><xref target="RFC4034"></xref><xref
target="RFC4035"></xref>.</t>
<t>Devices can also optionally update their own DNS record. For
example, a sensor that is using <xref target="RFC4862">Stateless
Address Autoconfiguration</xref> to create an address might want to
associate it with a name using <xref target="RFC2136">DNS Dynamic
Update</xref> or <xref target="RFC3007">DNS Secure Dynamic
Update</xref>.</t>
</section>
<section anchor="dhcp" title="Dynamic Host Configuration">
<t>As discussed in <xref target="ipv4"></xref>, IPv4 address
assignment is generally performed using <xref
target="RFC2131">DHCP</xref>. By contrast, <xref
target="ipv6"></xref> points out that IPv6 address assignment can be
accomplished using either <xref
target="RFC4862">autoconfiguration</xref><xref
target="RFC4941"></xref> or <xref target="RFC3315">DHCPv6</xref>.
The best argument for the use of autoconfiguration is a large number
of systems that require little more than a random number as an
address; the argument for DHCP is administrative control.</t>
<t>There are other parameters that may need to be allocated to hosts
requiring administrative configuration; examples include the
addresses of DNS servers, keys for Secure DNS and Network Time
servers.</t>
</section>
<section title="Network Time">
<t>The Network Time Protocol was originally designed by Dave Mills
of the University of Delaware and CSNET, implementing a temporal
metric in the Fuzzball Routing Protocol and generally coordinating
time experiments. The current versions of the time protocol are the
<xref target="RFC5905">Network Time Protocol</xref>.</t>
</section>
</section>
<section title="Network Management">
<t>The IETF has developed two protocols for network management: SNMP
and NETCONF. SNMP is discussed in <xref target="snmp"></xref>, and
NETCONF is discussed in <xref target="netconf"></xref>.</t>
<section anchor="snmp"
title="Simple Network Management Protocol (SNMP)">
<t>The Simple Network Management Protocol, originally specified in
the late 1980's and having passed through several revisions, is
specified in several documents: <list style="symbols">
<t><xref target="RFC3411">An Architecture for Describing Simple
Network Management Protocol (SNMP) Management
Frameworks</xref></t>
<t><xref target="RFC3412">Message Processing and
Dispatching</xref></t>
<t><xref target="RFC3413">SNMP Applications</xref></t>
<t><xref target="RFC3414">User-based Security Model (USM) for
SNMP version 3</xref></t>
<t><xref target="RFC3415">View-based Access Control Model
(VACM)</xref></t>
<t><xref target="RFC3416">Version 2 of the SNMP Protocol
Operations</xref></t>
<t><xref target="RFC3417">Transport Mappings</xref></t>
<t><xref target="RFC3418">Management Information Base
(MIB)</xref></t>
</list></t>
<t>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.</t>
</section>
<section anchor="netconf"
title="Network Configuration (NETCONF) Protocol">
<t>The NETCONF Configuration Protocol is specified in one basic
document, with supporting documents for carrying it over the IPS.
These documents include: <list style="symbols">
<t><xref target="RFC4741">NETCONF Configuration
Protocol</xref></t>
<t><xref target="RFC4742">Using the NETCONF Configuration
Protocol over Secure SHell (SSH)</xref></t>
<t><xref target="RFC4743">Using NETCONF over the Simple Object
Access Protocol (SOAP)</xref></t>
<t><xref target="RFC4744">Using the NETCONF Protocol over the
Blocks Extensible Exchange Protocol (BEEP)</xref></t>
<t><xref target="RFC5277">NETCONF Event Notifications</xref></t>
<t><xref target="RFC5539">NETCONF over Transport Layer Security
(TLS)</xref></t>
<t><xref target="RFC5717">Partial Lock Remote Procedure Call
(RPC) for NETCONF</xref></t>
</list></t>
<t>NETCONF was developed in response to operator requests for a
common configuration protocol based on ASCII text, unlike ASN.1. In
essence, it carries XML-encoded remote procedure call (RPC) data. In
response to Smart Grid requirements, there is consideration of a
variant of the protocol that could be used for polled and
event-driven management activities, and for both monitoring and
configuration of systems in the field.</t>
</section>
</section>
<section title="Service and Resource Discovery">
<t>Service and resource discovery are among the most important
protocols for constrained resource self-organizing networks. These
include various sensor networks as well as the Home Area Networks
(HANs), Building Area Networks (BANs) and Field Area Networks (FANs)
envisioned by Smart Grid architects.</t>
<section anchor="service-discovery" title="Service Discovery">
<t>Service discovery protocols are designed for the automatic
configuration and detection of devices, and the services offered by
the discovered devices. In many cases service discovery is performed
by so-called "constrained resource" devices (i.e., those with
limited processing power, memory, and power resources).</t>
<t>In general, service discovery is concerned with the resolution
and distribution of host names via <xref
target="I-D.cheshire-dnsext-multicastdns">multicast DNS</xref> and
the automatic location of network services via <xref
target="dhcp">DHCP</xref>, the <xref
target="I-D.cheshire-dnsext-dns-sd">DNS Service Discovery
(DNS-SD)</xref> (part of Apple's Bonjour technology) and the <xref
target="RFC2608">Service Location Protocol (SLP)</xref>.</t>
</section>
<section anchor="resource-discovery" title="Resource Discovery">
<t>Resource Discovery is concerned with the discovery of resources
offered by end-points and is extremely important in
machine-to-machine closed-loop applications (i.e., those with no
humans in the loop). The goals of resource discovery protocols
include: <list>
<t>Simplicity of creation and maintenance of resources</t>
<t>Commonly understood semantics</t>
<t>Conformance to existing and emerging standards</t>
<t>International scope and applicability</t>
<t>Extensibility</t>
<t>Interoperability among collections and indexing systems</t>
</list></t>
<t>The <xref target="I-D.ietf-core-coap">Constrained Application
Protocol (CoAP)</xref> is being developed in IETF with these goals
in mind. In particular, CoAP is designed for use in constrained
resource networks and for machine-to-machine applications such as
smart energy and building automation. It provides a RESTful transfer
protocol <xref target="RESTFUL"></xref>, a built-in resource
discovery protocol, and includes web concepts such as URIs and
content-types. CoAP provides both unicast and multicast resource
discovery and includes the ability to filter on attributes of
resource descriptions. Finally, CoAP resource discovery can also be
used to discover HTTP resources.</t>
<t>For simplicity, CoAP makes the assumption that all CoAP servers
listen on the default CoAP port or otherwise have been configured or
discovered using some general service discovery mechanism such as
<xref target="I-D.cheshire-dnsext-dns-sd">DNS Service Discovery
(DNS-SD)</xref>.</t>
<t>Resource discovery in CoAP is accomplished through the use of
well-known resources which describe the links offered by a CoAP
server. CoAP defines a well-known URI for discovery:
"/.well-known/r" <xref target="RFC5785"></xref>. For example, the
query [GET /.well-known/r] returns a list of links (representing
resources) available from the queried CoAP server. A query such as
[GET /.well-known/r?n=Voltage] returns the resources with the name
Voltage.</t>
</section>
</section>
<section anchor="other-app" title="Other Applications">
<t>There are many applications that rely on the IP infrastructure, but
are not properly thought of as part of the IP infrastructure itself.
These applications may be useful in the context of the Smart Grid. The
choices made when constructing a profile of the Internet Profile Suite
may impact how such applications could be used. Some of them, not by
any means an exhaustive list, are discussed here.</t>
<section title="Session Initiation Protocol">
<t>The <xref target="RFC3261">Session Initiation
Protocol</xref><xref target="RFC3265"></xref><xref
target="RFC3853"></xref><xref target="RFC4320"></xref><xref
target="RFC4916"></xref><xref target="RFC5393"></xref><xref
target="RFC5621"></xref> is an application layer control (signaling)
protocol for creating, modifying and terminating multimedia sessions
on the Internet, meant to be more scalable than H.323. Multimedia
sessions can be voice, video, instant messaging, shared data, and/or
subscriptions of events. SIP can run on top of TCP, UDP, SCTP, or
TLS over TCP. SIP is independent of the transport layer, and
independent of the underlying IPv4/v6 version. In fact, the
transport protocol used can change as the SIP message traverses SIP
entities from source to destination.</t>
<t>SIP itself does not choose whether a session is voice or video,
nor does it identify the actual endpoints' IP addresses. The <xref
target="RFC4566">SDP: Session Description Protocol</xref> is
intended for those purposes. Within the SDP, which is transported by
SIP, codecs are offered and accepted (or not), the port number and
IP address is decided for where each endpoint wants to receive their
<xref target="RFC3550">Real-time Transport Protocol (RTP)</xref>
packets. The introduction of Network Address Translation (NAT)
technology into the profile, whether IPv4/IPv4, IPv4/IPv as
described in <xref target="sect3.2.1.3"></xref>, or IPv6/IPv6,
increases the complexity of SIP/SDP deployment. This is further
discussed in <xref target="RFC2993"></xref> and <xref
target="RFC5626"></xref>.</t>
<t></t>
</section>
<section anchor="xmpp"
title="Extensible Messaging and Presence Protocol">
<t>The <xref target="RFC6120">Extensible Messaging and Presence
Protocol (XMPP)</xref> is a protocol for streaming Extensible Markup
Language (XML) elements in order to exchange structured information
in close to real time between any two network endpoints. Since XMPP
provides a generalized, extensible framework for exchanging XML
data, it has been proposed as an application structure for
interchange between embedded devices and sensors. It is currently
used for <xref target="RFC3921">Instant Messaging and
Presence</xref> and a wide variety of real-time communication modes.
These include multi-user chat, publish-subscribe, alerts and
notifications, service discovery, multimedia session management,
device configuration, and remote procedure calls. XMPP supports
channel encryption using <xref target="RFC5246">TLS</xref> and
strong authentication (including PKIX certificate authentication)
using <xref target="RFC4422">SASL</xref>. It also makes use of
Unicode-compliant addresses and <xref target="RFC3629">UTF-8</xref>
data exchange for internationalization.</t>
<t>XMPP allows for <xref target="RFC3923">End-to-End Signing and
Object Encryption </xref>, access to objects named using <xref
target="RFC4854"> Uniform Resource Names (URN) </xref>, and the use
of <xref target="RFC5122">Internationalized Resource Identifiers
(IRIs) and Uniform Resource Identifiers (URIs)</xref>, and the
presentation of <xref target="RFC5437"> Notifications </xref>.</t>
</section>
<section anchor="ical" title="Calendaring">
<t>Internet calendaring, as implemented in Apple iCal, Microsoft
Outlook and Entourage, and Google Calendar, is specified in <xref
target="RFC5545">Internet Calendaring and Scheduling Core Object
Specification (iCalendar)</xref> and is in the process of being
updated to an XML schema in <xref
target="I-D.daboo-et-al-icalendar-in-xml">iCalendar XML
Representation</xref> Several protocols exist to carry calendar
events, including <xref target="RFC5546"> iCalendar
Transport-Independent Interoperability Protocol (iTIP) </xref>, the
<xref target="RFC6047"> Message-Based Interoperability Protocol
(iMIP)</xref> , and open source work on the <xref target="RFC5023">
Atom Publishing Protocol</xref>.</t>
</section>
</section>
</section>
<section anchor="network"
title="A simplified view of the business architecture">
<t>The Internet is a network of networks in which networks are
interconnected in specific ways and are independently operated. It is
important to note that the underlying Internet architecture puts no
restrictions on the ways that networks are interconnected;
interconnection is a business decision. As such, the Internet
interconnection architecture can be thought of as a "business structure"
for the Internet.</t>
<t>Central to the Internet business structure are the networks that
provide connectivity to other networks, called "Transit Networks". These
networks sell bulk bandwidth and routing services to each other and to
other networks as customers. Around the periphery of the transit network
are companies, schools, and other networks that provide services
directly to individuals. These might generally be divided into
"Enterprise Networks" and "Access Networks"; Enterprise networks provide
"free" connectivity to their own employees or members, and also provide
them a set of services including electronic mail, web services, and so
on. Access Networks sell broadband connectivity (DSL, Cable Modem,
802.11 wireless or 3GPP wireless), or "dial" services including PSTN
dial-up and ISDN, to subscribers. The subscribers are typically either
residential or small office/home office (SOHO) customers. Residential
customers are generally entirely dependent on their access provider for
all services, while a SOHO buys some services from the access provider
and may provide others for itself. Networks that sell transit services
to nobody else - SOHO, residential, and enterprise networks - are
generally refereed to as "edge networks"; Transit Networks are
considered to be part of the "core" of the Internet, and access networks
are between the two. This general structure is depicted in <xref
target="business-architecture"></xref>.</t>
<figure anchor="business-architecture"
title="Conceptual model of Internet businesses">
<artwork align="center"><![CDATA[
------ ------
/ \ / \
/--\ / \ / \
|SOHO|---+ Access | |Enterprise|
\--/ | Service | | Network |
/--\ | Provider| | |
|Home|---+ | ------ | |
\--/ \ +---+ +---+ /
\ / / \ \ /
------ | Transit | ------
| Service |
| Provider |
| |
\ /
\ /
------
]]></artwork>
</figure>
<t>A specific example is shown in a traceroute from a home to a nearby
school. Internet connectivity in <xref target="traceroute"></xref>
passes through <list style="symbols">
<t>The home network,</t>
<t>Cox Communications, an Access Network using Cable Modem
technology,</t>
<t>TransitRail, a commodity peering service for research and
education (R&E) networks,</t>
<t>Corporation for Education Network Initiatives in California
(CENIC), a transit provider for educational networks, and</t>
<t>the University of California at Santa Barbara, which in this
context might be viewed as an access network for its students and
faculty or as an enterprise network.</t>
</list></t>
<figure anchor="traceroute"
title="Traceroute from residential customer to educational institution">
<artwork align="center"><![CDATA[
<stealth-10-32-244-218:> fred% traceroute www.ucsb.edu
traceroute to web.ucsb.edu (128.111.24.41),
64 hops max, 40 byte packets
1 fred-vpn (10.32.244.217) 1.560 ms 1.108 ms 1.133 ms
2 wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1) 12.540 ms ...
3 68.6.13.101 ...
4 68.6.13.129 ...
5 langbbr01-as0.r2.la.cox.net ...
6 calren46-cust.lsanca01.transitrail.net ...
7 dc-lax-core1--lax-peer1-ge.cenic.net ...
8 dc-lax-agg1--lax-core1-ge.cenic.net ...
9 dc-ucsb--dc-lax-dc2.cenic.net ...
10 r2--r1--1.commserv.ucsb.edu ...
11 574-c--r2--2.commserv.ucsb.edu ...
12 * * *
]]></artwork>
</figure>
<t>Another specific example could be shown in a traceroute from the home
through a Virtual Private Network (VPN tunnel) from the home, crossing
Cox Cable (an Access Network) and Pacific Bell (a Transit Network), and
terminating in Cisco Systems (an Enterprise Network); a traceroute of
the path doesn't show that as it is invisible within the VPN and the
contents of the VPN are invisible, due to encryption, to the networks on
the path. Instead, the traceroute in <xref target="enterprise"></xref>
is entirely within Cisco's internal network.</t>
<figure anchor="enterprise" title="Traceroute across VPN">
<artwork align="center"><![CDATA[
<stealth-10-32-244-218:~> fred% traceroute irp-view13
traceroute to irp-view13.cisco.com (171.70.120.60),
64 hops max, 40 byte packets
1 fred-vpn (10.32.244.217) 2.560 ms 1.100 ms 1.198 ms
<tunneled path through Cox and Pacific Bell>
2 ****
3 sjc24-00a-gw2-ge2-2 (10.34.251.137) 26.298 ms...
4 sjc23-a5-gw2-g2-1 (10.34.250.78) 25.214 ms ...
5 sjc20-a5-gw1 (10.32.136.21) 23.205 ms ...
6 sjc12-abb4-gw1-t2-7 (10.32.0.189) 46.028 ms ...
7 sjc5-sbb4-gw1-ten8-2 (171.*.*.*) 26.700 ms ...
8 sjc12-dc5-gw2-ten3-1 ...
9 sjc5-dc4-gw1-ten8-1 ...
10 irp-view13 ...
]]></artwork>
</figure>
<t>Note that in both cases, the home network uses private address space
<xref target="RFC1918"></xref> while other networks generally use public
address space, and that three middleware technologies are in use here.
These are the uses of a firewall, a Network Address Translator (NAT),
and a Virtual Private Network (VPN).</t>
<t>Firewalls are generally sold as and considered by many to be a
security technology. This is based on the fact that a firewall imposes a
border between two administrative domains. Typically, a firewall will be
deployed between a residential, SOHO, or enterprise network and its
access or transit provider. In its essence, a firewall is a data diode,
imposing a policy on what sessions may pass between a protected domain
and the rest of the Internet. Simple policies generally permit sessions
to be originated from the protected network but not from the outside;
more complex policies may permit additional sessions from the outside,
as electronic mail to a mail server or a web session to a web server,
and may prevent certain applications from global access even though they
are originated from the inside.</t>
<t>Note that the effectiveness of firewalls remains controversial. While
network managers often insist on deploying firewalls as they impose a
boundary, others point out that their value as a security solution is
debatable. This is because most attacks come from behind the firewall.
In addition, firewalls do not protect against application layer attacks
such as viruses carried in email. Thus, as a security solution,
firewalls are justified as a layer in defense in depth. That is, while
an end system must in the end be responsible for its own security, a
firewall can inhibit or prevent certain kinds of attacks, for example
the consumption of CPU time on a critical server.</t>
<t>Key documents describing firewall technology and the issues it poses
include: <list style="symbols">
<t><xref target="RFC2588">IP Multicast and Firewalls</xref></t>
<t><xref target="RFC2647">Benchmarking Terminology for Firewall
Performance</xref></t>
<t><xref target="RFC2979">Behavior of and Requirements for Internet
Firewalls</xref></t>
<t><xref target="RFC3511">Benchmarking Methodology for Firewall
Performance</xref></t>
<t><xref target="RFC4487">Mobile IPv6 and Firewalls: Problem
Statement</xref></t>
<t><xref target="RFC5207">NAT and Firewall Traversal Issues of Host
Identity Protocol Communication</xref></t>
</list></t>
<t>Network Address Translation is a technology that was developed in
response to ISP behaviors in the mid-1990's; when <xref
target="RFC1918"></xref> was published, many ISPs started handing out
single or small numbers of addresses, and edge networks were forced to
translate. In time, this became considered a good thing, or at least not
a bad thing; it amplified the public address space, and it was sold as
if it were a firewall. It of course is not; while traditional dynamic
NATs only translate between internal and external session address/port
tuples during the detected duration of the session, that session state
may exist in the network much longer than it exists on the end system,
and as a result constitutes an attack vector. The design, value, and
limitations of network address translation are described in: <list
style="symbols">
<t><xref target="RFC2663">IP Network Address Translator Terminology
and Considerations</xref></t>
<t><xref target="RFC3022">Traditional IP Network Address
Translator</xref></t>
<t><xref target="RFC3027">Protocol Complications with the IP Network
Address Translator</xref></t>
<t><xref target="RFC3235">Network Address Translator Friendly
Application Design Guidelines</xref></t>
<t><xref target="RFC3424">IAB Considerations for Network Address
Translation</xref></t>
<t><xref target="RFC3715">IPsec-Network Address Translation
Compatibility Requirements</xref></t>
<t><xref target="RFC4787">Network Address Translation Behavioral
Requirements for Unicast UDP</xref></t>
<t><xref target="RFC5128">State of Peer-to-Peer Communication across
Network Address Translators</xref></t>
<t><xref target="RFC5135">IP Multicast Requirements for a Network
Address Translator and a Network Address Port Translator</xref></t>
</list></t>
<t>Virtual Private Networks come in many forms; what they have in common
is that they are generally tunneled over the internet backbone, so that
as in <xref target="enterprise"></xref>, connectivity appears to be
entirely within the edge network although it is in fact across a service
provider's network. Examples include IPsec tunnel-mode encrypted
tunnels, IP-in-IP or GRE tunnels and <xref target="RFC3031">MPLS
LSPs</xref><xref target="RFC3032"></xref>. .</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This memo asks the IANA for no new parameters.</t>
<t>Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are required,
or if those assignments or registries are created during the RFC
publication process. From the author"s perspective, it may therefore be
removed upon publication as an RFC at the RFC Editor's discretion.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>Security is addressed in some detail in <xref
target="sect2.2"></xref> and <xref target="sect3.1"></xref>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Review comments were made by Adrian Farrel, Andrew
Yourtchenko, Ashok Narayanan, Bernie Volz, Chris Lonvick, Dan
Romascanu, Dave McGrew, Dave Oran, David Harrington, David
Su, Don Sturek, Francis Cleveland, Hemant Singh, James Polk,
Jari Arkko, John Meylor, Joseph Salowey, Julien Abeille, Kerry
Lynn, Lars Eggert, Magnus Westerlund, Murtaza Chiba, Paul
Duffy, Paul Hoffman, Peter Saint-Andre, Ralph Droms, Robert
Sparks, Russ White, Sean Turner, Sheila Frankel, Stephen
Farrell, Tim Polk, Toerless Eckert, Tom Herbst, Vint Cerf,
and Yoshihiro Ohba. Several suggested text, which was very
useful, as the authors don't claim to know half as much as
their reviewers collectively do.</t>
</section>
</middle>
<back>
<!-- references split to informative and normative -->
<references title="Normative References">
<?rfc include="reference.RFC.1122" ?>
<?rfc include="reference.RFC.1123" ?>
<?rfc include="reference.RFC.1812" ?>
<?rfc include="reference.RFC.4294" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-tcpm-tcp-security" ?>
<?rfc include="reference.I-D.ietf-opsec-ip-security" ?>
<?rfc include="reference.I-D.arkko-ipv6-transition-guidelines" ?>
<?rfc include="reference.I-D.cheshire-dnsext-dns-sd" ?>
<?rfc include="reference.I-D.cheshire-dnsext-multicastdns" ?>
<?rfc include="reference.I-D.daboo-et-al-icalendar-in-xml" ?>
<?rfc include="reference.I-D.ietf-6lowpan-hc" ?>
<?rfc include="reference.I-D.ietf-6man-node-req-bis" ?>
<?rfc include="reference.I-D.ietf-behave-dns64" ?>
<?rfc include="reference.I-D.ietf-behave-v6v4-framework" ?>
<?rfc include="reference.I-D.ietf-behave-v6v4-xlate" ?>
<?rfc include="reference.I-D.ietf-behave-v6v4-xlate-stateful" ?>
<?rfc include="reference.I-D.ietf-core-coap" ?>
<?rfc include="reference.I-D.ietf-dime-rfc3588bis" ?>
<?rfc include="reference.I-D.ietf-manet-dymo" ?>
<?rfc include="reference.I-D.ietf-oauth-v2" ?>
<?rfc include="reference.I-D.ietf-roll-rpl" ?>
<?rfc include="reference.I-D.ietf-tls-rfc4347-bis" ?>
<?rfc include="reference.I-D.lear-abfab-arch" ?>
<?rfc include="reference.I-D.mcgrew-tls-aes-ccm-ecc" ?>
<?rfc include="reference.RFC.0768" ?>
<?rfc include="reference.RFC.0791" ?>
<?rfc include="reference.RFC.0792" ?>
<?rfc include="reference.RFC.0793" ?>
<?rfc include="reference.RFC.0826" ?>
<?rfc include="reference.RFC.0894" ?>
<?rfc include="reference.RFC.1006" ?>
<?rfc include="reference.RFC.1964" ?>
<?rfc include="reference.RFC.2743" ?>
<?rfc include="reference.RFC.4120" ?>
<?rfc include="reference.RFC.4121" ?>
<?rfc include="reference.RFC.4253" ?>
<?rfc include="reference.RFC.4556" ?>
<?rfc include="reference.RFC.1034" ?>
<?rfc include="reference.RFC.1035" ?>
<?rfc include="reference.RFC.1058" ?>
<?rfc include="reference.RFC.1112" ?>
<?rfc include="reference.RFC.1195" ?>
<?rfc include="reference.RFC.1332" ?>
<?rfc include="reference.RFC.1661" ?>
<?rfc include="reference.RFC.1918" ?>
<?rfc include="reference.RFC.2080" ?>
<?rfc include="reference.RFC.2126" ?>
<?rfc include="reference.RFC.2131" ?>
<?rfc include="reference.RFC.2136" ?>
<?rfc include="reference.RFC.2328" ?>
<?rfc include="reference.RFC.2357" ?>
<?rfc include="reference.RFC.2453" ?>
<?rfc include="reference.RFC.2460" ?>
<?rfc include="reference.RFC.2464" ?>
<?rfc include="reference.RFC.2474" ?>
<?rfc include="reference.RFC.2475" ?>
<?rfc include="reference.RFC.2516" ?>
<?rfc include="reference.RFC.2545" ?>
<?rfc include="reference.RFC.2560" ?>
<?rfc include="reference.RFC.2588" ?>
<?rfc include="reference.RFC.2608" ?>
<?rfc include="reference.RFC.2615" ?>
<?rfc include="reference.RFC.2616" ?>
<?rfc include="reference.RFC.2647" ?>
<?rfc include="reference.RFC.2663" ?>
<?rfc include="reference.RFC.2710" ?>
<?rfc include="reference.RFC.2784" ?>
<?rfc include="reference.RFC.2865" ?>
<?rfc include="reference.RFC.2979" ?>
<?rfc include="reference.RFC.2993" ?>
<?rfc include="reference.RFC.3007" ?>
<?rfc include="reference.RFC.3022" ?>
<?rfc include="reference.RFC.3027" ?>
<?rfc include="reference.RFC.3031" ?>
<?rfc include="reference.RFC.3032" ?>
<?rfc include="reference.RFC.3168" ?>
<?rfc include="reference.RFC.3235" ?>
<?rfc include="reference.RFC.3261" ?>
<?rfc include="reference.RFC.3265" ?>
<?rfc include="reference.RFC.3275" ?>
<?rfc include="reference.RFC.3315" ?>
<?rfc include="reference.RFC.3376" ?>
<?rfc include="reference.RFC.3411" ?>
<?rfc include="reference.RFC.3412" ?>
<?rfc include="reference.RFC.3413" ?>
<?rfc include="reference.RFC.3414" ?>
<?rfc include="reference.RFC.3415" ?>
<?rfc include="reference.RFC.3416" ?>
<?rfc include="reference.RFC.3417" ?>
<?rfc include="reference.RFC.3418" ?>
<?rfc include="reference.RFC.3424" ?>
<?rfc include="reference.RFC.3436" ?>
<?rfc include="reference.RFC.3453" ?>
<?rfc include="reference.RFC.3511" ?>
<?rfc include="reference.RFC.3522" ?>
<?rfc include="reference.RFC.3550" ?>
<?rfc include="reference.RFC.3561" ?>
<?rfc include="reference.RFC.3569" ?>
<?rfc include="reference.RFC.3588" ?>
<?rfc include="reference.RFC.3590" ?>
<?rfc include="reference.RFC.3626" ?>
<?rfc include="reference.RFC.3629" ?>
<?rfc include="reference.RFC.3715" ?>
<?rfc include="reference.RFC.3810" ?>
<?rfc include="reference.RFC.3828" ?>
<?rfc include="reference.RFC.3853" ?>
<?rfc include="reference.RFC.6120" ?>
<?rfc include="reference.RFC.3921" ?>
<?rfc include="reference.RFC.3923" ?>
<?rfc include="reference.RFC.3971" ?>
<?rfc include="reference.RFC.3973" ?>
<?rfc include="reference.RFC.4017" ?>
<?rfc include="reference.RFC.4033" ?>
<?rfc include="reference.RFC.4034" ?>
<?rfc include="reference.RFC.4035" ?>
<?rfc include="reference.RFC.4108" ?>
<?rfc include="reference.RFC.4210" ?>
<?rfc include="reference.RFC.4213" ?>
<?rfc include="reference.RFC.4271" ?>
<?rfc include="reference.RFC.4291" ?>
<?rfc include="reference.RFC.4301" ?>
<?rfc include="reference.RFC.4302" ?>
<?rfc include="reference.RFC.4303" ?>
<?rfc include="reference.RFC.4307" ?>
<?rfc include="reference.RFC.4320" ?>
<?rfc include="reference.RFC.4340" ?>
<?rfc include="reference.RFC.4347" ?>
<?rfc include="reference.RFC.4364" ?>
<?rfc include="reference.RFC.4410" ?>
<?rfc include="reference.RFC.4422" ?>
<?rfc include="reference.RFC.4443" ?>
<?rfc include="reference.RFC.4487" ?>
<?rfc include="reference.RFC.4492" ?>
<?rfc include="reference.RFC.4566" ?>
<?rfc include="reference.RFC.4594" ?>
<?rfc include="reference.RFC.4601" ?>
<?rfc include="reference.RFC.4604" ?>
<?rfc include="reference.RFC.4607" ?>
<?rfc include="reference.RFC.4608" ?>
<?rfc include="reference.RFC.4614" ?>
<?rfc include="reference.RFC.4741" ?>
<?rfc include="reference.RFC.4742" ?>
<?rfc include="reference.RFC.4743" ?>
<?rfc include="reference.RFC.4744" ?>
<?rfc include="reference.RFC.4760" ?>
<?rfc include="reference.RFC.4787" ?>
<?rfc include="reference.RFC.4835" ?>
<?rfc include="reference.RFC.4854" ?>
<?rfc include="reference.RFC.4861" ?>
<?rfc include="reference.RFC.4862" ?>
<?rfc include="reference.RFC.4916" ?>
<?rfc include="reference.RFC.4919" ?>
<?rfc include="reference.RFC.4941" ?>
<?rfc include="reference.RFC.4944" ?>
<?rfc include="reference.RFC.4960" ?>
<?rfc include="reference.RFC.4987" ?>
<?rfc include="reference.RFC.5023" ?>
<?rfc include="reference.RFC.5061" ?>
<?rfc include="reference.RFC.5072" ?>
<?rfc include="reference.RFC.5122" ?>
<?rfc include="reference.RFC.5128" ?>
<?rfc include="reference.RFC.5135" ?>
<?rfc include="reference.RFC.5191" ?>
<?rfc include="reference.RFC.5207" ?>
<?rfc include="reference.RFC.5216" ?>
<?rfc include="reference.RFC.5238" ?>
<?rfc include="reference.RFC.5246" ?>
<?rfc include="reference.RFC.5272" ?>
<?rfc include="reference.RFC.5277" ?>
<?rfc include="reference.RFC.5280" ?>
<?rfc include="reference.RFC.5289" ?>
<?rfc include="reference.RFC.5308" ?>
<?rfc include="reference.RFC.5340" ?>
<?rfc include="reference.RFC.5393" ?>
<?rfc include="reference.RFC.5405" ?>
<?rfc include="reference.RFC.5430" ?>
<?rfc include="reference.RFC.5433" ?>
<?rfc include="reference.RFC.5437" ?>
<?rfc include="reference.RFC.5539" ?>
<?rfc include="reference.RFC.5545" ?>
<?rfc include="reference.RFC.5546" ?>
<?rfc include="reference.RFC.5548" ?>
<?rfc include="reference.RFC.5569" ?>
<?rfc include="reference.RFC.5621" ?>
<?rfc include="reference.RFC.5626" ?>
<?rfc include="reference.RFC.5652" ?>
<?rfc include="reference.RFC.5673" ?>
<?rfc include="reference.RFC.5681" ?>
<?rfc include="reference.RFC.5717" ?>
<?rfc include="reference.RFC.5740" ?>
<?rfc include="reference.RFC.5751" ?>
<?rfc include="reference.RFC.5785" ?>
<?rfc include="reference.RFC.5826" ?>
<?rfc include="reference.RFC.5838" ?>
<?rfc include="reference.RFC.5849" ?>
<?rfc include="reference.RFC.5867" ?>
<?rfc include="reference.RFC.5905" ?>
<?rfc include="reference.RFC.5932" ?>
<?rfc include="reference.RFC.5958" ?>
<?rfc include="reference.RFC.5996" ?>
<?rfc include="reference.RFC.5998"?>
<?rfc include="reference.RFC.6031" ?>
<?rfc include="reference.RFC.6047" ?>
<?rfc include="reference.RFC.6052"?>
<?rfc include="reference.RFC.6090" ?>
<reference anchor="r1822">
<front>
<title>Interface Message Processor -- Specifications for the
interconnection of a host and a IMP, Report No. 1822</title>
<author>
<organization>Bolt Beranek and Newman Inc.</organization>
</author>
<date month="January" year="1976" />
</front>
</reference>
<reference anchor="RESTFUL">
<front>
<title>Architectural Styles and the Design of Network-based Software
Architectures</title>
<author fullname="Roy Thomas Fielding" surname="Fielding">
<organization>University of California, Irvine</organization>
</author>
<date year="2000" />
</front>
</reference>
<reference anchor="IEC62351-3">
<front>
<title>POWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION EXCHANGE.
DATA AND COMMUNICATIONS SECURITY -- Part 3: Communication network
and system security Profiles including TCP/IP</title>
<author>
<organization>International Electrotechnical Commission Technical
Committee 57</organization>
</author>
<date month="May" year="2007" />
</front>
</reference>
<reference anchor="IEEE802.1X">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks - Port
based Network Access Control</title>
<author>
<organization>Institute of Electrical and Electronics
Engineers</organization>
</author>
<date month="February" year="2010" />
</front>
<seriesInfo name="IEEE" value="Standard 802.1X-2010" />
</reference>
<reference anchor="SP-MULPIv3.0">
<front>
<title>DOCSIS 3.0 MAC and Upper Layer Protocols Interface
Specification, CM-SP-MULPIv3.0-I10-090529</title>
<author fullname="CableLabs" surname="CableLabs">
<organization>Cisco Systems</organization>
</author>
<date month="May" year="2009" />
</front>
<format target="http://blogs.cisco.com/datacenter/comments/ethernet_over_barbed_wire_arcnet_100mb_token_ring_100base_vganylan_and_iscs/"
type="HTML" />
</reference>
<reference anchor="Model">
<front>
<title>Smart Grid Architecture Committee: Conceptual Model White
Paper
http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/SGIPConceptualModelDevelopmentSGAC/Smart_Grid_Conceptual_Model_20100420.doc</title>
<author fullname="SGIP" surname="SGIP">
<organization />
</author>
</front>
</reference>
<reference anchor="IEC61850">
<front>
<title>Wikipedia Article: IEC 61850
http://en.wikipedia.org/wiki/IEC_61850</title>
<author fullname="Wikipedia" surname="Wikipedia">
<organization />
</author>
</front>
</reference>
<reference anchor="SmartGrid">
<front>
<title>Wikipedia Article: Smart Grid
http://en.wikipedia.org/w/index.php?title=Smart_grid&oldid=415838933</title>
<author fullname="Wikipedia" surname="Wikipedia">
<organization></organization>
</author>
<date month="February" year="2011" />
</front>
</reference>
</references>
<section anchor="example"
title="Example: Advanced Metering Infrastructure ">
<t>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.</t>
<t><xref target="ami"></xref> 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.</t>
<figure anchor="ami"
title="The HAN, NAN, and Utility in the Advanced Metering Infrastructure">
<artwork align="center"><![CDATA[
---
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 +---------+
---
]]></artwork>
</figure>
<t>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: <list style="symbols">
<t>How does Demand Response work? Either: <list style="symbols">
<t>The utility presents pricing signals to the home,</t>
<t>The utility presents pricing signals individual devices
(e.g., a Pluggable Electric Vehicle),</t>
<t>The utility adjusts settings on individual appliances within
the home.</t>
</list></t>
<t>How does the utility access meters at the home? <list
style="symbols">
<t>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</t>
<t>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.</t>
</list></t>
</list></t>
<t>In implementation, these models are idealized; reality may include
some aspects of each model in specified cases.</t>
<t>The examples include: <list style="numbers">
<t><xref target="example1"></xref> presumes that the HAN, the NAN,
and the utility's network are separate administrative domains and
speak application to application across those domains.</t>
<t><xref target="example2"></xref> repeats the first example, but
presuming that the utility directly accesses appliances within the
HAN from the collector".</t>
<t><xref target="example3"></xref> 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.</t>
</list></t>
<section anchor="han-structure" title="How to structure a network">
<t>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 <xref target="r1822">BBN 1822</xref>. 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.</t>
<t>The Smart Grid is likely to see a similar evolution over time.
Consider the Home Area Network (HAN) as a readily understandable small
network. At this juncture, technologies proposed for residential
networks include IEEE P1901, various versions of IEEE 802.15.4, and
IEEE 802.11. It is reasonable to expect other technologies to be
developed in the future. As the Zigbee Alliance has learned (and as a
resulted incorporated the IPS in Smart Energy Profile 2.0), there is
significant value in providing a virtual address that is mapped to
interfaces or nodes attached to each of those technologies.</t>
<figure anchor="han-ems-router"
title="Two views of a Home Area Network">
<artwork align="center"><![CDATA[
Utility NAN
/
/
+----+-----+ +--+ +--+ +--+
| Meter | |D1| |D2| |D3|
+-----+----+ ++-+ ++-+ ++-+
| | | |
----+-+-------+----+----+---- IEEE 802.15.4
|
+--+---+
|Router+------/------ Residential Broadband
+--+---+
|
----+---------+----+----+---- IEEE P1901
| | |
++-+ ++-+ ++-+
|D4| |D5| |D6|
+--+ +--+ +--+
A thermostats, appliances, etc
| ------+----------------+------------------
|"HAN" | |
| +---+---+ +---+---+
| |Router | | Meter |
| |or EMS | | |
V +---+---+ +---+---+
--- | --- \
| ^ \ | /
| |"NAN" \ | /
---+--- | +--+-+-+---+
/ \ | |"Pole Top"|
| Internet| v +----+-----+
\ / ---
-------
]]></artwork>
</figure>
<t>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.</t>
<t><xref target="han-ems-router"></xref> shows two simple networks,
one of which IEEE 802.15.4 and IEEE 1901 domains, and one of which
uses an arbitrary LAN within the home, which could be IEEE
802.3/Ethernet, IEEE 802.15.4, IEEE 1901, IEEE 802.11, or anything
else that made sense in context. Both show the connectivity between
them as a router separate from the EMS. This is for clarity; the two
could of course be incorporated into a single system, and one could
imagine appliances that want to communicate with their manufacturers
supporting both a HAN interface and a WiFi interface rather than
depending on the router. These are all manufacturer design
decisions.</t>
<!--
! Notes from call:
!
! ULA
! 15.4 to 802.11 routing
! not using DHCP (SLACK on 15.4)
! ESI not providing firewall (not packet forwarding statefull
! firewall) no upnp/firewall traversal in the meter
!
! ESI doesn't make your HAN a utility network
! a node on your home network for specific network function
! e.g tivo .. transport
! ESI need to be capable of understanding that 15.4 don't
! normally occur in home networks; they do want to set up networks
! in homes with just a thermost and meter; in absence of other
! network, meter does it.
!
! use home network as model, meter added to network, just a wifi
! device
!
-->
<section title="HAN Routing">
<t>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
<xref target="RFC3315">DHCP</xref>). 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.</t>
<t>The ESI is a node on the user's residential network, and will not
typically provide stateful packet forwarding or firewall services
between the HAN and the utility network(s). In general, the ESI is a
node on the home network; in some cases, the meter may act as the
ESI. However, the ESI must be capable of understanding that most
home networks are not 802.15.4 enabled (rather, they are typically
802.11 networks), and that it must be capable of setting up ad-hoc
networks between various sensors in the home (e.g., between the
meter and say, a thermostat) in the event there aren't other
networks available.</t>
</section>
<section anchor="han-security" title="HAN Security">
<t>In any network, we have a variety of threats and a variety of
possible mitigations. These include, at minimum: <list
style="hanging">
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
<t hangText="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.</t>
</list></t>
<t>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.</t>
</section>
</section>
<section anchor="example1" title="Model 1: AMI with separated domains">
<t>With the background given in <xref target="han-structure"></xref>,
we can now discuss the use of IP (IPv4 or IPv6) in the AMI.</t>
<t>In this first model, consider the three domains in <xref
target="ami"></xref> 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.</t>
<t>In this case, as shown in <xref target="han-ems-router"></xref>, 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.</t>
<t>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.</t>
<t>In this scenario, Quality of Service (QoS) issues reportedly arise
when high precedence messages must be sent through the collector to
the home; if the collector is occupied polling the meters or doing
some other task, the application may not yield control of the
processor to the application that services the message. Clearly, this
is either an application or an Operating System problem; applications
need to be designed in a manner that doesn't block high precedence
messages. The collector also needs to use appropriate NAN services, if
they exist, to provide the NAN QoS it needs. For example, if WiMax is
in use, it might use a routine-level service for normal exchanges but
a higher precedence service for these messages.</t>
</section>
<section anchor="example2"
title="Model 2: AMI with neighborhood access to the home">
<t>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.</t>
<figure anchor="han-nan-router" title="Home Area Network">
<artwork align="center"><![CDATA[
+----------+ +--+ +--+ +--+
| Meter | |D1| |D2| |D3|
+-----+----+ ++-+ ++-+ ++-+
| | | |
----+-+-------+----+----+---- IEEE 802.15.4
|
+--+---+
| +------/------ NAN
|Router|
| +------/------ Residential Broadband
+--+---+
|
----+---------+----+----+---- IEEE P1901
| | |
++-+ ++-+ ++-+
|D4| |D5| |D6|
+--+ +--+ +--+
]]></artwork>
</figure>
<t>In this case, as shown in <xref target="han-nan-router"></xref>,
the Meter, and EMS as hosts on the HAN, and there is a router between
the HAN and the NAN.</t>
<t>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 <xref
target="han-security"></xref> 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.</t>
<t>In addition to the QoS issues raised in <xref
target="example1"></xref>, 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 <xref
target="RFC4594"></xref>, and let other traffic use the Standard
Service Class or other service classes.</t>
</section>
<section anchor="example3" title="Model 3: Collector is an IP router">
<t>In this third model, the relationship between the NAN and the HAN
is either as in <xref target="example1"></xref> or <xref
target="example2"></xref>; 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.</t>
<t>As and analogous to <xref target="example2"></xref>, there are
serious security considerations in this model. Traffic being forwarded
should be filtered, and the issues raised in <xref
target="han-security"></xref> 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.</t>
<t>In addition to the QoS issues raised in <xref
target="example1"></xref>, 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 <xref
target="RFC4594"></xref>, and let other traffic use the Standard
Service Class or other service classes.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:35:23 |