One document matched: draft-baker-ietf-core-11.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-11" 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="2010" />
<area>General</area>
<workgroup></workgroup>
<abstract>
<t>This note identifies the key protocols of the Internet Protocol Suite
for use in the Smart Grid. The target audience is those people seeking
guidance on how to construct an appropriate Internet Protocol Suite
profile for the Smart Grid. In practice, such a profile would consist of
selecting what is needed for Smart Grid deployment from the picture
presented here.</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"></xref>.</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 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 protocols that are
critical in integrating Smart Grid devices into an IP-based
infrastructure.</t>
<t>The IPS provides options for several key architectural components.
For example, the IPS provides several choices for the traditional
transport function between two systems: the Transmission Control
Protocol (TCP) <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="suite"></xref> describes the Internet Architecture
and its protocol suite.</t>
<t><xref target="protocols"></xref> outlines the set of protocols
that will be useful in Smart Grid deployment.</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="suite" 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="architecture" 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 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="RFC1157"></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 title="Transport">
<t>The term "transport" is perhaps among the most confusing concepts
in the communication architecture, to large extent because people
with various backgrounds use it to refer to "the layer below that
which I am interested in, which gets my data to my peer". For
example, optical network engineers refer to optical fiber and
associated electronics as "the transport", while web designers refer
to the Hypertext Transfer Protocol (HTTP) <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 includes the delivery of data (either as a stream
of messages or a stream of bytes) in a stated sequence with stated
expectations regarding delivery rate and loss. For example, TCP will
reduce rate to avoid loss, while DCCP accepts some level of loss if
necessary to maintain timeliness.</t>
</section>
<section 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 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 different network
technologies. This is the layer that allows diverse networks such
as Ethernet, 802.15.4, etc. to be combined into a uniform IP
network. New network technologies can be introduced into the IP
Protocol Suite by defining how IP is carried over those
technologies, leaving the other layers of the IPS and applications
that use those protocol unchanged.</t>
</section>
<section title="Lower layer networks">
<t>The network layer can recursively subdivided as needed. This
may be accomplished by tunneling, in which an IP datagram is
encapsulated in another IP header for delivery to a decapsulator.
IP is frequently carried in Virtual Private Networks (VPNs) across
the public Internet using tunneling technologies such as the
Tunnel mode of IPsec, IP-in-IP, and Generic Route Encapsulation
(GRE) <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 local wireless (IEEE 802.11, 802.15.4, or 802.16)
networks and switched Ethernet (IEEE 802.3) networks.</t>
</section>
</section>
<section 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="security-issues" title="Security issues">
<t>While it is popular to complain about the security of the Internet,
solutions to many Internet security problems already exist but have
either not been widely deployed, may impact critical performance
criteria, or require security measures outside the IPS. Internet
security solutions attempt to mitigate a set of known threats within
the IPS domain at a specified cost; addressing security issues
requires first a threat analysis and assessment and a set of
mitigations appropriate to the threats. Since we have threats at every
layer, we should expect to find mitigations at every layer.</t>
<section title="Physical 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 untappable; we have
since learned to tap it by bending the fiber and collecting
incidental light, and we have learned about backhoes. As a result,
some installations encase fiber optic cable in a pressurized sheath,
both to quickly identify the location of a cut and to make it more
difficult to tap.</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>
</section>
<section title="Network, Transport, and Application Layer Session Authentication">
<t>At the network, transport, and application layers, and in lower
layer networks where dynamic connectivity such as ATM Switched
Virtual Circuits (SVCs) or "dial" connectivity are in use, there
tend to be several different classes of authentication/authorization
requirements. The basic requirements that must be satisfied are:
<list style="numbers">
<t>Verify that peers are appropriate partners; this generally
means knowing "who" they are and that they have a "need to know"
or are trusted sources.</t>
<t>Verify that information that appears to be from a trusted
peer is in fact from that peer.</t>
<t>Validate the content of the data exchanged; it must conform
to the rules of the exchange.</t>
<t>Defend the channel against denial of service attacks.</t>
<t>Ensure the integrity of the information transported to defend
against modification attacks.</t>
</list></t>
<t>In other words, both the communications channel itself and
message exchanges (both by knowing the source of the information and
to have proof of its validity) must be secured. Three examples
suffice to illustrate the challenges.</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.
Experience has shown that by including information in the transport
header or a related protocol like the IPsec (<xref
target="ipsec"></xref>) or TLS (<xref target="tls"></xref>), 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 communication with a
router or a service. For example, an unauthorized party might try to
join the routing system. To protect against such attacks, an
Internet Service Provider (ISP) should not accept information from
new peers without verifying that the peer is who it claims to be and
that the peer is authorized to carry on the exchange of
information.</t>
<t>More generally, in order to secure a communications channel, it
must be possible to verify that messages putatively received from a
peer were in fact received from that peer. Only once messages are
verified as coming a trusted peer should a host or router engage in
communications with the peer.</t>
<t>Unfortunately, even trusted peers forward incorrect or malicious
data. As a result, securing the channel is not sufficient;
information exchanged through the channel must also be secured. In
electronic mail and other database exchanges, it may be necessary to
be able to verify the identity of the sender and the correctness of
the content long after the information exchange has occurred - for
example, if a contract is exchanged that is secured by digital
signatures, one will wish to be able to verify those signatures at
least throughout the lifetime of the contract, and probably a long
time after that.</t>
</section>
<section title="Confidentiality">
<t>In addition to securing the communications channel and messaging,
there is frequently a requirement for confidentiality.
Confidentiality arises at several layers, sometimes simultaneously.
For example, providers of credit card transaction services want
application layer privacy, which can be supplied by encrypting
application data or by an encrypted transport layer. If an ISP (or
other entity) wants to hide its network structure, it can decide to
encrypt the network layer header.</t>
</section>
</section>
<section anchor="infra" 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="dns" 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 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 is a polled
architecture, 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 does
not have specific solutions 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="protocols" 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 privacy, Authentication,
Authorization, and Accounting (AAA), transport and network solution
dimensions. The following sections provide guidance for such
analyzes.</t>
<section anchor="security-solutions" title="Security solutions">
<t>As noted, a key consideration in security solutions is a good
threat analysis coupled with appropriate mitigation strategies at each
layer. The following sections outline the security features of the
IPS.</t>
<section title="Session identification, authentication, authorization, and accounting">
<t>The IPS provides approaches to Authentication, Authorization, and
Accounting (AAA) issues. Since these different approaches have
different attack surfaces and protection domains, they require some
thought in application. The two major approaches to AAA taken by the
IPS are the IP Security Architecture (<xref target="ipsec"></xref>),
which protects IP datagrams, and Transport Layer Security (<xref
target="tls"></xref>), which protects the information which the
transport layer delivers.</t>
</section>
<section anchor="ipsec" title="IP Security Architecture (IPsec)">
<t>The <xref target="RFC4301">Security Architecture for the Internet
Protocol (IPsec)</xref> is a set of control and data protocols that
are implemented between IPv4 and the chosen transport layer, or in
IPv6's security extension header. It allows transport layer sessions
to communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery. As is typical with IETF
specifications, the architecture is spelled out in a number of
documents which specify the specific components: the <xref
target="RFC4302">IP Authentication Header (AH)</xref> <xref
target="RFC4303">Encapsulating Security Payload (ESP)</xref>, <xref
target="RFC5996">Internet Key Exchange (IKEv2) </xref>, <xref
target="RFC4307">Cryptographic Algorithms</xref>, <xref
target="RFC4835">Cryptographic Algorithm Implementation Requirements
for ESP and AH</xref>, and the use of <xref
target="RFC4309">Advanced Encryption Standard (AES) </xref>.</t>
<t>IPsec provides two modes: Transport mode and tunnel mode. In
transport mode, IPsec ESP encrypts the transport layer and the
application data. In tunnel mode, the source IP datagram is
encrypted and encapsulated in a second IP header addressed to the
intended decryptor. As might be expected, tunnel mode is frequently
used for virtual private networks which need to securely transmit
data across networks with unknown (or no) other security properties.
In both cases, authentication, authorization, and confidentiality
extend from system to system, and apply to all applications that the
two systems use.</t>
<t>Note that IPsec can provide non-repudiation when an asymmetric
authentication algorithm is used with the AH header and both sender
and receiver keys are used in the authentication calculation.
However, the default authentication algorithm is keyed MD5, which
like all symmetric algorithms cannot provide non-repudiation by
itself (since the sender's key is not used in the computation). So
while IPsec provides a means of authenticating network level objects
(packets), these objects are are ephemeral and not directly
correlated with a particular application. As a result
non-repudiation is not generally applicable to network level objects
such as packets.</t>
</section>
<section anchor="tls" title="Transport Layer Security (TLS)">
<t><xref target="RFC5246">Transport Layer Security</xref> and <xref
target="RFC4347">Datagram Transport Layer Security</xref><xref
target="I-D.ietf-tls-rfc4347-bis"></xref> are mechanisms that travel
within the transport layer protocol data unit, meaning that they
readily traverse network address translators and secure the
information exchanges without securing the datagrams exchanged or
the transport layer itself. Each allows client/server applications
to communicate in a way that is designed to prevent eavesdropping,
tampering, or message forgery. Authentication, authorization, and
confidentiality exist for a session between specific
applications.</t>
<t>In order to communicate securely, a TLS client and TLS server
must agree on the cryptographic algorithms and keys that they will
use on the secured connection. In particular, they must agree on
these items:</t>
<t><list style="symbols">
<t>Key Establishment Algorithm</t>
<t>Peer Authentication Algorithm</t>
<t>Bulk Data Encryption Algorithm and key size</t>
<t>Digest Algorithm</t>
</list></t>
<t>Since each category has multiple options, the number of possible
combinations is large. As a result, TLS does not allow all possible
combinations of choices; rather it only allows certain well-defined
combinations known as Cipher Suites. Examples of the use of Cipher
Suites include <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>, <xref
target="I-D.mcgrew-tls-aes-ccm">AES-CCM</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.</t>
<t>Used in conjunction with <xref target="RFC5216">EAP-TLS</xref>,
<xref target="IEEE802.1X">IEEE 802.1X</xref> is a widely deployed
mechanism providing access security for wired or wireless IEEE 802
LANs. <xref target="RFC5193">Protocol for Carrying Authentication
for Network Access (PANA)</xref> is also gaining traction, as Zigbee
IP has chosen PANA using EAP-TLS for network access security.</t>
</section>
<section title="Secure/Multipurpose Internet Mail Extensions (S/MIME)">
<t>The <xref target="RFC2045">S/MIME</xref> <xref
target="RFC2046"></xref> <xref target="RFC2047"></xref> <xref
target="RFC4289"></xref> <xref target="RFC2049"></xref> <xref
target="RFC5750"></xref> <xref target="RFC5751"></xref> <xref
target="RFC4262"></xref> specification was originally designed as an
extension to SMTP Mail to provide evidence that the putative sender
of an email message in fact sent it, and that the content received
was in fact the content that was sent. As its name suggests, by
extension this is a way of securing any object that can be
exchanged, by any means, and has become one of the most common ways
to secure an object.</t>
<t>Related work includes the use of digital signatures on
XML-encoded files, which has been jointly standardized by W3C and
the IETF <xref target="RFC3275"></xref>.</t>
</section>
</section>
<section 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 since IPv4 free pool (the pool of available, unallocated
IPv4 addresses) is almost exhausted, the IETF recommends that new
deployments use IPv6 and that IPv4 infrastructures are supported via
the mechanisms described in <xref target="transition"></xref>.</t>
<section anchor="transition" 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="DualStack" 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 similarly support both protocols,
and</t>
<t>require that all new systems 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="6rd" 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="v6v4"
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 does however have the advantage that it does
not require that a unique IPv4 address be embedded in the IPv6
address of hosts using this mechanism.</t>
<t>Finally, note that some networks site networks are IPv6 only
while some transits networks are IPv4 only. In these cases it may
be necessary to tunnel IPv6 over IPv4 or translate between IPv6
and IPv4.</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 equipment
identify each other's addresses using <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; 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="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>. These are considered experimental.</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. Autoconfiguation enables various different models
of network management which may be advantageous in various 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> or <xref
target="RFC3971">SEcure Neighbor Discovery (SEND)</xref>.</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 device
within a distributed subnet. As with protocols designed for wired
networks, routing is calculated and maintained whenever changes
are detected, and maintained in each router's tables. The set of
nodes that operate as routers within the subnet, however, are
fairly fluid, and dependent on this instantaneous topology of the
subnet.</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>A the highest level, the multicast model works as follows:
hosts express their interest in receiving multicast traffic from a
source by sending a Join message to their first hop router. That
router in turn sends a Join message upstream towards the root of
the tree, grafting the router (leaf node) onto the distribution
tree for the group. Data is delivered down the tree toward the
leaf nodes, which forward it onto the local network for
delivery.</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 all that well. As a result, the use of UDP really
should be treated as designing a new transport. Advice on the use of
UDP in new applications can be found in <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, we generally use 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 End to End research group
has published a <xref target="RFC4614">Roadmap for TCP Specification
Documents</xref> to capture this history, to guide TCP implementors,
and provide context for TCP researchers.</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 (as
opposed to TCP's byte streams). The design of SCTP includes
appropriate congestion avoidance behavior and resistance to flooding
and masquerade attacks. As it uses a message stream interface as
opposed to TCP's byte stream interface, it may also be more
appropriate for the ISO Transport Service than RFC 1006/2126.</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 as a result 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
which require 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, for the purpose of
implementing a temporal metric in the Fuzzball Routing Protocol and
generally coordinating time experiments. The current versions of the
time protocol are the <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 as opposed to
ASN.1. In essence, it carries XML-encoded remote procedure call
(RPC) data. In response to Smart Grid requirements, there is
consideration of a variant of the protocol that could be used for
polled and event-driven management activities, and for both
monitoring and configuration of systems in the field.</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 hostnames 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 discover 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 several applications that are widely used but are not
properly thought of as infrastructure.</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,
the <xref target="RFC4566">SDP: Session Description Protocol</xref>
is intended for that purpose and to identify the actual endpoints'
IP addresses. Within the SDP, which is transported by SIP, codecs
are offered and accepted (or not), the port number and IP address is
decided for where each endpoint wants to receive their <xref
target="RFC3550">Real-time Transport Protocol (RTP)</xref> packets.
This part is critical to understand because of the affect on Network
Address Translators, or NATs. Unless a NAT (with or without a
firewall) is designed to be SDP aware (i.e., looking into each
packet far enough to discover what the IP address and port number is
for this particular session - and resetting it based on the <xref
target="RFC5389">Session Traversal Utilities for NAT</xref>, the
session established by SIP will not result in RTP packets being sent
to the proper endpoint (in SIP called a user agent, or UA). It
should be noted that SIP messaging has no issues with NATs, it is
just the UA's inability to generally learn about the presence of the
NATs that prevent the RTP packets from being received by the UA
establishing the session.</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="RFC2447"> 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 use 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 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/aport
tuples during the detected duration of the session, that session state
may exist in the network much longer than it exists on the end system,
and as a result constitutes an attack vector. The design, value, and
limitations of network address translation are described in: <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="security-issues"></xref> and <xref
target="security-solutions"></xref>.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Review comments were made by Andrew Yourtchenko, Ashok Narayanan,
Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, Don
Sturek, Francis Cleveland, Hemant Singh, James Polk, John Meylor, Joseph
Salowey, Julien Abeille, Kerry Lynn, Magnus Westerlund, Murtaza Chiba,
Paul Duffy, Paul Hoffman, Ralph Droms, Russ White, Sheila Frankel, Tom
Herbst, and Toerless Eckert. Dave McGrew, Vint Cerf, and Ralph Droms
suggested text.</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.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.RFC.6052"?>
<?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-manet-dymo" ?>
<?rfc include="reference.I-D.ietf-roll-rpl" ?>
<?rfc include="reference.I-D.ietf-tls-rfc4347-bis" ?>
<?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.1034" ?>
<?rfc include="reference.RFC.1035" ?>
<?rfc include="reference.RFC.1058" ?>
<?rfc include="reference.RFC.1112" ?>
<?rfc include="reference.RFC.1157" ?>
<?rfc include="reference.RFC.1195" ?>
<?rfc include="reference.RFC.1332" ?>
<?rfc include="reference.RFC.1661" ?>
<?rfc include="reference.RFC.1918" ?>
<?rfc include="reference.RFC.2045" ?>
<?rfc include="reference.RFC.2046" ?>
<?rfc include="reference.RFC.2047" ?>
<?rfc include="reference.RFC.2049" ?>
<?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.2447" ?>
<?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.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.2979" ?>
<?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.3550" ?>
<?rfc include="reference.RFC.3561" ?>
<?rfc include="reference.RFC.3569" ?>
<?rfc include="reference.RFC.3590" ?>
<?rfc include="reference.RFC.3626" ?>
<?rfc include="reference.RFC.3715" ?>
<?rfc include="reference.RFC.3810" ?>
<?rfc include="reference.RFC.3828" ?>
<?rfc include="reference.RFC.3853" ?>
<?rfc include="reference.RFC.3971" ?>
<?rfc include="reference.RFC.3973" ?>
<?rfc include="reference.RFC.4033" ?>
<?rfc include="reference.RFC.4034" ?>
<?rfc include="reference.RFC.4035" ?>
<?rfc include="reference.RFC.4213" ?>
<?rfc include="reference.RFC.4262" ?>
<?rfc include="reference.RFC.4271" ?>
<?rfc include="reference.RFC.4289" ?>
<?rfc include="reference.RFC.4291" ?>
<?rfc include="reference.RFC.4301" ?>
<?rfc include="reference.RFC.4302" ?>
<?rfc include="reference.RFC.4303" ?>
<?rfc include="reference.RFC.5996" ?>
<?rfc include="reference.RFC.4307" ?>
<?rfc include="reference.RFC.4309" ?>
<?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.4443" ?>
<?rfc include="reference.RFC.4487" ?>
<?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.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.5128" ?>
<?rfc include="reference.RFC.5135" ?>
<?rfc include="reference.RFC.5193" ?>
<?rfc include="reference.RFC.5207" ?>
<?rfc include="reference.RFC.5216" ?>
<?rfc include="reference.RFC.5238" ?>
<?rfc include="reference.RFC.5246" ?>
<?rfc include="reference.RFC.5277" ?>
<?rfc include="reference.RFC.5308" ?>
<?rfc include="reference.RFC.5340" ?>
<?rfc include="reference.RFC.5389" ?>
<?rfc include="reference.RFC.5393" ?>
<?rfc include="reference.RFC.5405" ?>
<?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.5681" ?>
<?rfc include="reference.RFC.5673" ?>
<?rfc include="reference.RFC.5717" ?>
<?rfc include="reference.RFC.5740" ?>
<?rfc include="reference.RFC.5750" ?>
<?rfc include="reference.RFC.5751" ?>
<?rfc include="reference.RFC.5785" ?>
<?rfc include="reference.RFC.5826" ?>
<?rfc include="reference.RFC.5838" ?>
<?rfc include="reference.RFC.5867" ?>
<?rfc include="reference.RFC.5905" ?>
<?rfc include="reference.RFC.4492" ?>
<?rfc include="reference.RFC.5289" ?>
<?rfc include="reference.RFC.5430" ?>
<?rfc include="reference.RFC.5932" ?>
<?rfc include="reference.I-D.mcgrew-tls-aes-ccm" ?>
<?rfc include="reference.I-D.mcgrew-tls-aes-ccm-ecc" ?>
<reference anchor="1822">
<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" />
<format target="http://blogs.cisco.com/datacenter/comments/ethernet_over_barbed_wire_arcnet_100mb_token_ring_100base_vganylan_and_iscs/"
type="HTML" />
</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 BBN 1822 <xref target="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., betweeen 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>
<!-- LocalWords: Cisco ttcol SCTP DCCP IETF RFCs internet SNMP HTTP MPLS SVCs
-->
<!-- LocalWords: connectionless GMPLS untappable IPsec DNSSEC NetConf DHCP
-->
<!-- LocalWords: DOCSIS IKEv decryptor autoconfiguration ICMP OSPF unicast
-->
<!-- LocalWords: multicast NACK SRMP ICMPv LoWPAN DHCPv autoconfigured SEcure
-->
<!-- LocalWords: Autoconfiguation RIPng OSPFv CLNS AODV DYMO OLSR MLDv MBPS
-->
<!-- LocalWords: GBPS HDLC PPPoE SONET DCCP's Roadmap TCP's CSNET Fuzzball
-->
<!-- LocalWords: codecs NATs UA's iCal Google iCalendar Interoperability iTIP
-->
<!-- LocalWords: iMIP PSTN ISDN traceroute TransitRail CENIC fred Cisco's
-->
<!-- LocalWords: Internets UCSB middleware ISPs aport LSPs IANA Yourtchenko
-->
<!-- LocalWords: Ashok Narayanan Volz Lonvick McGrew Hemant Singh Meylor Vint
-->
<!-- LocalWords: Salowey Julien Abeille Magnus Westerlund Murtaza Droms iSCSI
-->
<!-- LocalWords: Toerless Eckert MULPIv Arcnet VGAnylan decapsulator VPNs
-->
<!-- LocalWords: IETF's stateful reassembly Zigbee HANs BANs FANs hostnames
-->
<!-- LocalWords: CoAP RESTful URIs PGWs FERC NERC BAA's NASPI estimatation
-->
<!-- LocalWords: NAPSInet DiffServ VACM SHell Synchro Phasor NASPInet RAPIR
-->
<!-- LocalWords: PMUs Synchrophasors NANs WiFi APIs Homeplug UPnP SSIDs https
-->
<!-- LocalWords: DKIM repudiability WiMAX telecom WiMax NETL KTAs HVDC mortem
-->
<!-- LocalWords: phasor DERs timestamping phasors synchrophasor SCADA SOLs
-->
<!-- LocalWords: sychrophasor baselining islanding PDCs Apps ISOs RTOs VPLS
-->
<!-- LocalWords: Electrotechnical SynchroPhasor LDAP ACLs LANs UAPN PMU's
-->
<!-- LocalWords: Unicasting unicasted UAPNs utilty's UAPMs WAPN UAPM WAPNs
-->
<!-- LocalWords: NASPINet ECDH ECDSA TCBs Datagram datagram tuple Multi IEEE
-->
<!-- LocalWords: datagrams datagram's mitigations proven PANA SMTP versa
-->
<!-- LocalWords: natively other's subnet subnets reachability Lossy tradeoff
-->
<!-- LocalWords: acknowledgement implementors Bonjour tuples Beranek Headend
-->
<!-- LocalWords: Pluggable ARPANET
-->
| PAFTECH AB 2003-2026 | 2026-04-23 19:35:23 |