Internet Protocols
for the Smart GridCisco SystemsSanta Barbara93117CaliforniaUSAfred@cisco.comCisco SystemsEugene97403OregonUSAdmm@cisco.com
General
This note identifies the key infrastructure protocols of the Internet
Protocol Suite for use in the Smart Grid. The target audience is those
people seeking guidance on how to construct an appropriate Internet
Protocol Suite profile for the Smart Grid. In practice, such a profile
would consist of selecting what is needed for Smart Grid deployment from
the picture presented here.This document provides Smart Grid designers with advice on how to
best "profile" the Internet Protocol Suite (IPS) for use in Smart Grids.
It provides an overview of the IPS and the key infrastructure protocols
that are critical in integrating Smart Grid devices into an IP-based
infrastructure.In the words of the Wikipedia , A Smart Grid is a form of electricity network utilizing digital
technology. A Smart Grid delivers electricity from suppliers to
consumers using two-way digital communications to control appliances
at consumers' homes; this saves energy, reduces costs and increases
reliability and transparency. It overlays the ordinary electrical
Grid with an information and net metering system, that includes
smart meters. Smart Grids are being promoted by many governments as
a way of addressing energy independence, global warming and
emergency resilience issues.A Smart Grid is made possible by applying sensing, measurement
and control devices with two-way communications to electricity
production, transmission, distribution and consumption parts of the
power Grid that communicate information about Grid condition to
system users, operators and automated devices, making it possible to
dynamically respond to changes in Grid condition.A Smart Grid includes an intelligent monitoring system that keeps
track of all electricity flowing in the system. It also has the
capability of integrating renewable electricity such as solar and
wind. When power is least expensive the user can allow the smart
Grid to turn on selected home appliances such as washing machines or
factory processes that can run at arbitrary hours. At peak times it
could turn off selected appliances to reduce demand.Other names for a Smart Grid (or for similar proposals) include
smart electric or power Grid, intelligent Grid (or intelliGrid),
futureGrid, and the more modern interGrid and intraGrid.That description focuses on the implications of Smart Grid technology
in the home of a consumer. In fact, data communications technologies of
various kinds are used throughout the Grid, to monitor and maintain
power generation, transmission, and distribution, as well as the
operations and management of the Grid. One can view the Smart Grid as a
collection of interconnected computer networks that connects and serves
the needs of public and private electrical utilities and their
customers.At this writing, there is no single document that can be described as
comprising an internationally agreed standard for the Smart Grid; that
is in part the issue being addressed in its development. The nearest
approximations are probably the Smart Grid Interoperability Panel's
Conceptual Model and documents comprising
.The Internet Protocol Suite (IPS) provides options for numerous
architectural components. For example, the IPS provides several choices
for the traditional transport function between two systems: the
Transmission Control Protocol (TCP) , the
Stream Control Transmission Protocol (SCTP) , and the Datagram Congestion Control Protocol
(DCCP) . Another option is to select an
encapsulation such as the User Datagram Protocol (UDP) which essentially allows an application to
implement its own transport service. In practice, a designer will pick a
transport protocol which is appropriate to the problem being solved.The IPS is standardized by the Internet Engineering Task Force
(IETF). IETF protocols are documented in the Request for Comment (RFC)
series. Several RFCs have been written describing how the IPS should be
implemented. These include: Requirements for Internet Hosts -
Communication Layers,Requirements for Internet Hosts -
Application and Support,Requirements for IP Version 4
Routers, andIPv6 Node Requirements,At this writing, RFC 4294 is in the process of being updated, in
.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: describes the Internet Architecture
and its protocol suite. outlines a set of protocols that may
be useful in Smart Grid deployment. It is not exhaustive.Finally, provides an overview of
the business architecture embodied in the design and deployment of
the IPS.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.While Internet architecture uses the definitions and language
similar to language used by the ISO Open System Interconnect Reference
(ISO-OSI) Model (), 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.The structure of the Internet reference model is shown in .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) 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 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.The term "transport" is perhaps among the most confusing concepts
in the communication architecture, to a large extent because people
with various backgrounds use it to refer to "the layer below that
which I am interested in, which gets my data to my peer". For
example, optical network engineers refer to optical fiber and
associated electronics as "the transport", while web designers refer
to the Hypertext Transfer Protocol (HTTP) (an application layer protocol) as "the
transport".In the Internet protocol stack, the "transport" is the lowest
protocol layer that travels end-to-end unmodified, and is
responsible for end-to-end data delivery services. In the Internet
the transport layer is the layer above the network layer. Transport
layer protocols have a single minimum requirement: the ability to
multiplex several applications on one IP address. UDP, TCP,
DCCP, SCTP, and NORM
each accomplish this using a pair of port numbers, one for the
sender and one for the receiver. A port number identifies an
application instance, which might be a general "listener" that peers
or clients may open sessions with, or a specific correspondent with
such a "listener". The session identification in an IP datagram is
often called the "five-tuple", and consists of the source and
destination IP addresses, the source and destination ports, and an
identifier for the transport protocol in use.In addition, the responsibilities of a specific transport layer
protocol typically include the delivery of data (either as a stream
of messages or a stream of bytes) in a stated sequence with stated
expectations regarding delivery rate and loss. For example, TCP will
reduce its rate in response to loss, as a congestion control
trigger, while DCCP accepts some level of loss if necessary to
maintain timeliness.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) 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.IPv4 and IPv6, each of which is called the Internet Protocol,
are connectionless ("datagram") architectures. They are designed
as common elements that interconnect network elements across a
network of lower layer networks. In addition to the basic service
of identifying a datagram's source and destination, they offer
services to fragment and reassemble datagrams when necessary,
assist in diagnosis of network failures, and carry additional
information necessary in special cases.The Internet layer provides a uniform network abstraction
network that hides the differences between various network
technologies. This is the layer that allows diverse networks such
as Ethernet, 802.15.4, etc. to be combined into a uniform IP
network. New network technologies can be introduced into the IP
Protocol Suite by defining how IP is carried over those
technologies, leaving the other layers of the IPS and applications
that use those protocol unchanged.The network layer can be recursively subdivided as needed. This
may be accomplished by tunneling, in which an IP datagram is
encapsulated in another IP header for delivery to a decapsulator.
IP is frequently carried in Virtual Private Networks (VPNs) across
the public Internet using tunneling technologies such as the
Tunnel mode of IPsec, IP-in-IP, and Generic Route Encapsulation
(GRE) . In addition, IP is also
frequently carried in circuit networks such as MPLS , GMPLS, and ATM. Finally, IP is also
carried over wireless networks (IEEE 802.11, 802.15.4, or 802.16)
and switched Ethernet (IEEE 802.3) networks.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.While it is popular to complain about the security of the Internet,
it is important to distinguish between attacks on protocols and
attacks on user (e.g., phishing). Attacks on users are largely
independent of protocol details, reflecting interface design issues or
user education problems, and are out of scope for this document.
Security problems with Internet protocols are in scope, of course, and
can often be mitigated using existing security features already
specified for the protocol, or by leveraging the security services
offered by other IETF protocols. See the Security Assessment of the
Transmission Control Protocol (TCP) and the Security Assessment of the
Internet Protocol version 4 for more information on TCP and
IPv4 issues, respectively.These solutions do, however, need to get deployed as well. The road
to widespread deployment can sometimes be painful since often multiple
stakeholders need to take actions. Experience has shown that this
takes some time, and very often only happens when the incentives are
high enough in relation to the costs.Furthermore, it is important to stress that available standards are
important but the range of security problems is larger than a missing
standard; many security problems are the result of implementation bugs
and the result of certain deployment choices. While these are outside
the realm of standards development, they play an important role in the
security of the overall system. Security has to be integrated into the
entire process.The IETF takes security seriously in the design of their protocols
and architectures; every IETF specification has to have a security
consideration section to document the offered security threats and
countermeasures. RFC 3522 provides
recommendations writing such a security consideration section. It also
describes the classical Internet security threat model and lists
common security goals.In a nutshell, security has to be integrated into every protocol,
protocol extension, and consequently, every layer of the protocol
stack to be useful. We illustrate this also throughout this document
with references to further security discussions. Our experience has
shown that dealing with it as an afterthought does not lead to the
desired outcome.The discussion of security threats and available security
mechanisms aims to illustrate some of the design aspects that commonly
appear.At the physical and data link layers, threats generally center on
physical attacks on the network - the effects of backhoes,
deterioration of physical media, and various kinds of environmental
noise. Radio-based networks are subject to signal fade due to
distance, interference, and environmental factors; it is widely
noted that IEEE 802.15.4 networks frequently place a metal ground
plate between the meter and the device that manages it. Fiber was at
one time deployed because it was believed to be untrappable; we have
since learned to tap it by bending the fiber and collecting
incidental light, and we have learned about backhoes. As a result,
some installations encase fiber optic cable in a pressurized sheath,
both to quickly identify the location of a cut and to make it more
difficult to tap.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.For wireless transmission technologies, eavesdropping on the
transmitted frames is also typically a concern. Additionally, those
operating networks may want to ensure to restrict access to their
infrastructure to those who are authenticated and authorized
(typically called 'network access authentication'). This procedure
is often offered by security primitives at the data link layer.At the network, transport, and application layers, it is common
to demand a few basic security requirements, commonly referred to as
CIA (Confidentiality, Integrity, and Availability):Confidentiality: Protect the transmitted data from
unauthorized disclosure (i.e., keep eavesdroppers from learning
what was transmitted). For example, for trust in e-commerce
applications credit card transactions are exchanged encrypted
between the Web browser and a Web server.Integrity: Protect against unauthorized changes to exchanges,
including both intentional change or destruction and accidental
change or loss, by ensuring that changes to exchanges are
detectable. It has two parts: one for the data and one for the
peers. Peers need to verify that information that appears to be
from a trusted peer is really from that peer. This is
typically called 'data origin authentication'.Peers need to validate that the content of the data
exchanged is unmodified. The term typically used for this
property is data integrity.Availability: Ensure that the resource is accessible by
mitigating of denial of service attacks.To this we add authenticity, which requires that the
communicating peers prove that they are in fact who they say they
are to each other (i.e., mutual authentication). This generally
means knowing "who" the peer is, and that they demonstrate the
possession of a "secret" as part of the security protocol
interaction.The following three examples aim to illustrate these security
requirements.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.A number of mechanisms have been developed to deal with these
types of denial of service attacks. One, SYN Cookies, delays state
establishment on the server side to a later phase in the protocol
exchange. Another mechanism, specifically targeting the reset attack
cited above, provides authentication services in TCP itself to
ensure that fake resets are rejected.Another approach would be to offer security protection already at
a lower layer, such as IPsec (see )
or TLS (see ), so that a host can
identify legitimate messages and discard the others, thus mitigating
any damage that may have been caused by the attack.Another common attack involves unauthorized access to resources.
For example, an unauthorized party might try to attach to a network.
To protect against such an attack, an Internet Service Provider
(ISP) typically requires network access authentication of new hosts
demanding access to the network and to the Internet prior to
offering access. This exchange typically requires authentication of
that entity and a check in the ISPs back-end database to determine
whether corresponding subscriber records exist and still valid (e.g.
active subscription and sufficient credits).From the discussion above, establishing a secure communication
channel is clearly an important concept frequently used to mitigate
a range of attacks. Unfortunately, focusing only on channel security
may not be enough for a given task. Threat models have evolved and
even some of the communication endpoints cannot be considered fully
trustworthy, i.e. even trusted peers may act maliciously.Furthermore, many protocols are more sophisticated in their
protocol interaction and involve more than two parties in the
protocol exchange. Many of the application layer protocols, such as
email, instant messaging, voice over IP, and presence based
applications, fall into this category. With this class of protocols
in addition to secure channels between two parties also security
between non-neighboring communication partners need to be
considered. A detailed treatment of the security threats and
requirements of these multi-party protocols is beyond this
specification but the interested reader is referred to the
above-mentioned examples for an illustration of what technical
mechanisms have been investigated and proposed in the past.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.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 .Network management has proven to be a difficult problem. As such,
various solutions have been proposed, implemented, and deployed.
Each solution has its proponents, all of whom have solid arguments
for their viewpoints. The IETF has two major network management
solutions for device operation: SNMP, which is ASN.1-encoded and is
primarily used for monitoring of system variables, and NetConf , which is XML-encoded and primarily used
for device configuration.Another aspect of network management is the initial provisioning
and configuration of hosts, which is discussed in . Note that Smart Grid deployments may require
identity authentication and authorization (as well as other
provisioning and configuration) that may not be within the scope of
either DHCP or Neighbor Discovery. While the IP Protocol Suite has
limited support for secure provisioning and configuration, these
problems have been solved using IP protocols in specifications such
as DOCSIS 3.0.In this section, having briefly laid out the IP architecture and some
of the problems that the architecture tries to address, we introduce
specific protocols that might be appropriate to various Smart Grid use
cases. Use cases should be analyzed along with privacy, Authentication,
Authorization, and Accounting (AAA), transport and network solution
dimensions. The following sections provide guidance for such
analysis.As noted, a key consideration in security solutions is a good
threat analysis coupled with appropriate mitigation strategies at each
layer. The IETF has over time developed a number of building blocks
for security based on the observation that protocols often demand
similar security services. The following sub-sections outline a few of
those commonly used security building blocks. Re-using them offers
several advantages, such as availability of open source code,
experience with existing systems, a number of extensions that have
been developed, and the confidence that the listed technologies have
been reviewed and analyzed by a number of security experts.It is important to highlight that in addition to the mentioned
security tools every protocol often comes with additional, often
unique security considerations that are unique to the specific domain
that protocol operates in. Many protocols include features
specifically designed to mitigate these protocol-specific risks. In
other cases, the security considerations will identify
security-relevant services that are required from other network layers
to achieve appropriate levels of security.While the term AAA sounds generic and applicable to all sorts of
security protocols it has been, in the IETF, used in relation to
network access authentication and is associated with the RADIUS
() and the Diameter protocol (, ) in particular.The authentication procedure for network access aims to deal with
the task of verifying that a peer is authenticated and authorized
prior to accessing a particular resource (often connectivity to the
Internet). Typically, the authentication architecture for network
access consists of the following building blocks: the Extensible
Authentication Protocol (EAP ) as a
container to encapsulate EAP methods, an EAP Method (as a specific
way to perform cryptographic authentication and key exchange, such
as RFC 5216 , RFC 5433 ), a protocol that carries EAP payloads
between the end host and a server side entity (such as a network
access server), and a way to carry EAP payloads to back-end server
infrastructure (potentially in a cross-domain scenario) to provide
authorization and accounting functionality. The latter part is
provided by RADIUS and Diameter. To carry EAP payloads between the
end host and a network access server different mechanisms have been
standardized, such as PANA and IEEE 802.1X . For access to remote
networks, such as enterprise networks, the ability to utilize EAP
within IKEv2 has also been
developed.More recently, the same architecture with EAP and RADIUS/Diameter
is being re-used for application layer protocols. More details about
this architectural variant can be found in .IP security, as described in ,
addresses security at the IP layer, provided through the use of a
combination of cryptographic and protocol security mechanisms. It
offers a set of security services for traffic at the IP layer, in
both the IPv4 and IPv6 environment. The set of security services
offered includes access control, connectionless integrity, data
origin authentication, detection and rejection of replays (a form of
partial sequence integrity), confidentiality (via encryption), and
limited traffic flow confidentiality. These services are provided at
the IP layer, offering protection in a standard fashion for all
protocols that may be carried over IP (including IP itself).The architecture foresees a split between the rather
time-consuming (a) authentication and key exchange protocol step
that also establishes a security association; a data structure with
keying material and security parameters and (b) the actual data
traffic protection.For the former step the Internet Key Exchange protocol version 2
(IKEv2 ) is the most recent edition of
the standardized protocol. IKE negotiates each of the cryptographic
algorithms that will be used to protect the data independently,
somewhat like selecting items a la carte.For the actual data protection two types of protocols have
historically been used, namely the IP Authentication Header (AH)
and the Encapsulating Security
Payload (ESP) . The two differ in the
security services they offer; the most important distinction is that
ESP offers confidentiality protection while AH does not. Since ESP
can also provide authentication services, most recent protocol
development making use of IPsec only specify use of ESP and do not
use AH.In addition to these base line protocol mechanisms a number of
extensions have been developed for IKEv2 (e.g., an extension to
perform EAP-only authentication ) and
since the architecture supports flexible treatment of cryptographic
algorithms a number of them have been specified (e.g., for IKEv2, and for AH and ESP).Transport Layer Security v1.2 are
security services that protect data above the transport layer. The
protocol allows client/server applications to communicate in a way
that is designed to prevent eavesdropping, tampering, or message
forgery. TLS is application protocol independent.TLS is composed of two layers: the TLS Record protocol and the
TLS Handshake protocol. The TLS Record protocol provides connection
security that has two basic properties: (a) confidentiality
protection and (b) integrity protection.The TLS Handshake protocol allows the server and client to
authenticate each other and to negotiate an encryption algorithm and
cryptographic keys before the application protocol transmits or
receives its first byte of data. The negotiated parameters and the
derived keying material is then used by the TLS Record protocol to
perform its job.Unlike IKEv2/IPsec TLS negotiates these cryptographic parameters
in suites, so-called cipher suites. Examples of cipher suites that
can be negotiated with TLS include Elliptic
Curve Cryptography (ECC) , Camellia, and the Suite B Profile. outlines the use of different TLS Cipher
Suites for use in the Smart Grid. The basic cryptographic mechanisms
for ECC have been documented in .TLS must run over a reliable transport channel -- typically TCP.
In order to offer the same security services for unreliable datagram
traffic, such as UDP, the Datagram Transport Layer Security (DTLS
) was developed.In certain cases the application layer independent security
mechanisms described in the previous sub-sections are not sufficient
to deal with all the identified threats. For this purpose, a number
of security primitives are additionally available at the application
layer where the semantic of the application can be considered.We will focus with our description on a few mechanisms that are
commonly used throughout the Internet.Cryptographic Message Syntax (CMS )
is an encapsulation syntax to sign, digest, authenticate, or encrypt
arbitrary message content. It also allows arbitrary attributes, such
as signing time, to be signed along with the message content, and it
provides for other attributes such as countersignatures to be
associated with a signature. The CMS can support a variety of
architectures for certificate-based key management, such as the one
defined by the PKIX (Public Key Infrastructure using X.509) working
group . CMS has been leveraged to
supply security services in a variety of protocols, including secure
email , key management and , and
firmware updates .Related work includes the use of digital signatures on
XML-encoded documents, which has been jointly standardized by W3C
and the IETF . Digitally signed XML is
a good choice where applications natively support XML encoded data,
such as XMPP.More recently, the work on delegated authentication and
authorization often demanded by Web applications have been developed
with the Open Web Authentication (OAuth) protocol , .
OAuth is used by third-party applications to gain access to
protected resources (such as energy consumption information about a
specific household), without having the resource owner to shares its
long-term credentials with that third-party. In OAuth, the
third-party application requests access to resources controlled by
the resource owner and hosted by the resource server, and is issued
a different set of credentials than those of the resource owner.
More specifically, the third-party applications obtains an access
token, a string denoting a specific scope, duration, and other
access attributes, during the OAuth protocol exchange securely gain
access to the protected resource with the consent of the resource
owner.The IPS specifies two network layer protocols: IPv4 and IPv6. The
following sections describe the IETF's coexistence and transition
mechanisms for IPv4 and IPv6.Note that on 3 February 2011 the IANA's IPv4 free pool (the pool of
available, unallocated IPv4 addresses) was exhausted, and the RIR free
pools are expected to be exhausted during them coming year at most.
The IETF, the IANA, and the Regional Internet Registrars recommends
that new deployments use IPv6, and that IPv4 infrastructures are
supported via the mechanisms described in .The IETF has specified a variety of mechanisms designed to
facilitate IPv4/IPv6 coexistence. The IETF actually recommends
relatively few of them: the current advice to network operators is
found in Guidelines for Using
IPv6 Transition Mechanisms. The thoughts in that document are
replicated here.The simplest coexistence approach is to provide a network that routes both IPv4 and IPv6,ensure that servers and their applications similarly
support both protocols, andrequire that all new systems and applications purchased or
upgraded support both protocols.The net result is that over time all systems become protocol
agnostic, and that eventually maintenance of IPv4 support becomes
a business decision. This approach is described in the Basic Transition Mechanisms for IPv6 Hosts and
Routers.In those places in the network that support only IPv4 the
simplest and most reliable approach is to provide virtual
connectivity using tunnels or encapsulations. Early in the IPv6
deployment, this was often done using static tunnels. A more
dynamic approach is documented in IPv6
Rapid Deployment on IPv4 Infrastructures (6rd).In those cases where an IPv4-only host would like to
communicate with an IPv6-only host (or vice versa), protocol
translation may be indicated. At first blush, protocol translation
may appear trivial; on deeper inspection, it turns out that
protocol translation can be complicated.The most reliable approach to protocol translation is to
provide application layer proxies or gateways, which natively
enable application-to-application connections using both protocols
and can use whichever is appropriate. For example, a web proxy
might use both protocols and as a result enable an IPv4-only
system to run HTTP across on IPv6-only network or to a web server
that implements only IPv6. Since this approach is a service of a
protocol-agnostic server, it is not the subject of standardization
by the IETF.For those applications in which network layer translation is
indicated, the IETF has designed a translation mechanism which is
described in the following documents: Framework for
IPv4/IPv6 TranslationIPv6 Addressing of IPv4/IPv6
TranslatorsDNS
extensionsIP/ICMP
Translation AlgorithmTranslation from
IPv6 Clients to IPv4 ServersAs with IPv4/IPv4 Network Address Translation, translation
between IPv4 and IPv6 has limited real world applicability for an
application protocol which carry IP addresses in its payload and
expects those addresses to be meaningful to both client and
server. However, for those protocols that do not, protocol
translation can provide a useful network extension.Network-based translation provides for two types of services:
stateless (and therefore scalable and load-sharable) translation
between IPv4 and IPv6 addresses that embed an IPv4 address in
them, and stateful translation similar to IPv4/IPv4 translation
between IPv4 addresses. The stateless mode is straightforward to
implement, but due to the embedding, requires IPv4 addresses to be
allocated to an otherwise IPv6-only network, and is primarily
useful for IPv4-accessible servers implemented in the IPv6
network. The stateful mode allows clients in the IPv6 network to
access servers in the IPv4 network, but does not provide such
service for IPv4 clients accessing IPv6 peers or servers with
general addresses; it has the advantage that it does not require
that a unique IPv4 address be embedded in the IPv6 address of
hosts using this mechanism.Finally, note that some site networks are IPv6 only while some
transit networks are IPv4 only. In these cases, it may be
necessary to tunnel IPv6 over IPv4 or translate between IPv6 and
IPv4.IPv4 and the Internet Control Message Protocol comprise
the IPv4 network layer. IPv4 provides unreliable delivery of
datagrams.IPv4 also provides for fragmentation and reassembly of long
datagrams for transmission through networks with small Maximum
Transmission Units (MTU). The MTU is the largest packet size that
can be delivered across the network. In addition, the IPS provides
the Internet Control Message Protocol (ICMP) , which is a separate protocol that enables
the network to report errors and other issues to hosts that
originate problematic datagrams.IPv4 originally supported an experimental type of service field
that identified eight levels of operational precedence styled after
the requirements of military telephony, plus three and later four
bit flags that OSI IS-IS for IPv4 (IS-IS)
and OSPF Version 2 interpreted
as control traffic; this control traffic is assured of not being
dropped when queued or upon receipt, even if other traffic is being
dropped.. These control bits turned out to be less useful than the
designers had hoped. They were replaced by the Differentiated Services Architecture, which contains a six bit code point used
to select an algorithm (a "per-hop behavior") to be applied to the
datagram. The IETF has also produced a set of Configuration Guidelines for DiffServ Service
Classes, which describes a set of service classes that may be
useful to a network operator.IPv4 addresses are administratively assigned, usually using
automated methods, and assigned using the Dynamic Host Configuration Protocol
(DHCP). On most interface types, neighboring systems
identify each other's addresses using the Address Resolution Protocol (ARP).Routing for the IPv4 Internet is accomplished by routing
applications that exchange connectivity information and build
semi-static destination routing databases. If a datagram is
directed to a given destination address, the address is looked up
in the routing database, and the most specific ("longest") prefix
found that contains it is used to identify the next hop router, or
the end system it will be delivered to. This is not generally
implemented on hosts, although it can be; a host normally sends
datagrams to a router on its local network, and the router carries
out the intent.IETF specified routing protocols include RIP Version 2, OSI
IS-IS for IPv4, OSPF Version
2, and BGP-4. Active research
exists in mobile ad hoc routing and other routing paradigms; these
result in new protocols and modified forwarding paradigms.IPv4 was originally specified as a unicast (point to point)
protocol, and was extended to support multicast in . This uses the Internet Group Management Protocol to enable applications to join multicast
groups, and for most applications uses Source-Specific Multicast for routing and
delivery of multicast messages.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.In that research, the IETF imposed guidelines on the research community
regarding what was desirable. Important results from that research
include a number of papers and several proprietary protocols
including some that have been used in support of business
operations. RFCs in the area include The
Use of Forward Error Correction (FEC) in Reliable Multicast
, the Negative-acknowledgment
(NACK)-Oriented Reliable Multicast (NORM) Protocol , and
the Selectively Reliable Multicast
Protocol (SRMP) .IPv6, with the Internet Control Message Protocol "v6",
constitutes the next generation protocol for the Internet. IPv6
provides for transmission of datagrams from source to destination
hosts, which are identified by fixed length addresses.IPv6 also provides for fragmentation and reassembly of long
datagrams by the originating host, if necessary, for transmission
through "small packet" networks. ICMPv6, which is a separate
protocol implemented along with IPv6, enables the network to report
errors and other issues to hosts that originate problematic
datagrams.IPv6 adopted the Differentiated Services
Architecture, which contains a
six bit code point used to select an algorithm (a "per-hop
behavior") to be applied to the datagram.The IPv6 over Low-Power Wireless Personal
Area Networks RFC and the Compression Format for IPv6 Datagrams
in 6LoWPAN Networks 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.An IPv6 Address may be
administratively assigned using DHCPv6 in a manner similar to the way IPv4
addresses are. In addition, IPv6 addresses may also be
autoconfigured. Autoconfiguration enables various models of
network management which may be advantageous in different use
cases. Autoconfiguration procedures are defined in and . IPv6
neighbors identify each other's addresses using either Neighbor Discovery (ND). SEcure Neighbor Discovery (SEND) may be
used to secure these operations.Routing for the IPv6 Internet is accomplished by routing
applications that exchange connectivity information and build
semi-static destination routing databases. If a datagram is
directed to a given destination address, the address is looked up
in the routing database, and the most specific ("longest") prefix
found that contains it is used to identify the next hop router, or
the end system it will be delivered to. Routing is not generally
implemented on hosts (although it can be); generally, a host sends
datagrams to a router on its local network, and the router carries
out the intent.IETF specified routing protocols include RIP for IPv6, IS-IS
for IPv6, OSPF for IPv6, and
BGP-4 for IPv6. 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.The prototypical routing protocol used in the Internet has
probably been the Routing Information
Protocol. People that use it today tend to deploy RIPng for IPv6 and RIP Version 2. 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. provides guidance to algorithm designers
to mitigate these issues.The Open Shortest Path First (OSPF) routing protocol is one of
the more widely used protocols in the Internet. OSPF is a based on
Dijkstra's well known shortest path first (SPF) algorithm. It is
implemented as OSPF Version 2 for
IPv4, OSPF for IPv6 for IPv6, and
the Support of Address Families in
OSPFv3 to enable to route
both IPv4 and IPv6.The advantage of any SPF-based protocol (i.e., OSPF and IS-IS)
is primarily that every router in the network constructs its view
of the network from first hand knowledge rather than the "gossip"
that distance vector protocols propagate. As such, the topology is
quickly and easily changed by simply announcing the change. The
disadvantage of SPF-based protocols is that each router must store
a first-person statement of the connectivity of each router in the
domain.The Intermediate System to Intermediate System (IS-IS) routing
protocol is one of the more widely used protocols in the Internet.
IS-IS is also based on Dijkstra's SPF algorithm. It was originally
specified as ISO DP 10589 for the routing of CLNS, and extended
for routing in TCP/IP and dual
environments, and more recently for routing of IPv6 .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.The Border Gateway Protocol (BGP)
is widely used in the IPv4 Internet to exchange routes
between administrative entities - service providers, their peers,
their upstream networks, and their customers - while applying
specific policy. Multi-protocol Extensions
to BGP allow BGP to carry IPv6
Inter-Domain Routing, multicast reachability information,
and VPN information, among others.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.The Mobile Ad Hoc Working Group of the IETF developed, among
other protocols, the Ad hoc On-Demand
Distance Vector (AODV) Routing. This protocol captured the
minds of some in the embedded devices industry, but experienced
issues in wireless networks such as 802.15.4 and 802.11's Ad Hoc
mode. As a result, it is in the process of being updated in the
Dynamic MANET On-demand (DYMO)
Routing protocol.AODV and DYMO are essentially reactive routing protocols
designed for mobile ad hoc networks, and usable in other forms of
ad hoc networks. They provide connectivity between a device within
a distributed subnet and a few devices (including perhaps a
gateway or router to another subnet) without tracking connectivity
to other devices. In essence, routing is calculated and discovered
upon need, and a host or router need only maintain the routes that
currently work and are needed.The Optimized Link State Routing
Protocol (OLSR) is a proactive routing protocol designed
for mobile ad hoc networks, and can be used in other forms of ad
hoc networks. It provides arbitrary connectivity between systems
within a distributed subnet. As with protocols designed for wired
networks, routing is calculated and maintained whenever changes
are detected, and maintained in each router's tables. The set of
nodes that operate as routers within the subnet, however, are
fairly fluid, and dependent on this instantaneous topology of the
subnet.The IPv6 Routing Protocol for Low power and Lossy Networks
(RPL) is a reactive
routing protocol designed for use in resource constrained
networks. Requirements for resource constrained networks are
defined in , , , and
.Briefly, a constrained network is comprised of nodes that:Are built with limited processing power and memory, and
sometimes energy when operating on batteries.Are interconnected through a low-data-rate network
interface and potentially vulnerable to communication
instability and low packet delivery rates.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).IPv6 specifies both unicast and multicast datagram exchange. This
uses the Multicast Listener Discovery
Protocol (MLDv2) to enable
applications to join multicast groups, and for most applications
uses Source-Specific Multicast for
routing and delivery of multicast messages.The mechanisms experimentally developed for reliable multicast in
IPv4, discussed in , can be used in
IPv6 as well.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.The multicast model works as follows: hosts express their
interest in receiving multicast traffic from a source by sending a
Join message to their first hop router. That router in turn sends
a Join message upstream towards the root of the tree, grafting the
router (leaf node) onto the distribution tree for the group. Data
is delivered down the tree toward the leaf nodes, which forward it
onto the local network for delivery.The initial multicast model deployed in the Internet was known
as Any-Source Multicast (ASM). In the ASM model any host could
send to the group, and inter-domain multicast was difficult.
Protocols such as Protocol Independent
Multicast - Dense Mode (PIM-DM): Protocol Specification
(Revised) and Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised) were designed for the ASM model.Many modern multicast deployments use Source-Specific Multicast
(PIM-SSM) . 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.In general, the layered architecture of the Internet enables the
IPS to run over any appropriate layer two architecture. The ability
to change the link or physical layer without having to rethink the
network layer, transports, or applications has been a great benefit
in the Internet.Examples of link layer adaptation technology include: 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 . IPv6 does the same using .The IETF has defined a serial line protocol,
the Point-to-Point Protocol (PPP),
that uses HDLC (bit-synchronous or byte synchronous) framing.
The IPv4 adaptation specification is , and the IPv6 adaptation specification
is . Current use of this protocol
is in traditional serial lines, authentication exchanges in DSL
networks using PPP Over Ethernet
(PPPoE), and in the Digital Signaling Hierarchy
(generally referred to as Packet-on-SONET/SDH) using PPP over SONET/SDH.The adaptation specification for
IPv6 transmission over IEEE 802.15.4 Networks is .Numerous other adaptation specifications exist, including ATM,
Frame Relay, X.25, other standardized and proprietary LAN
technologies, and others.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.The User Datagram Protocol and the
Lightweight User Datagram Protocol are
properly not "transport" protocols in the sense of "a set of rules
governing the exchange or transmission of data electronically
between devices". They are labels that provide for multiplexing of
applications directly on the IP layer, with transport functionality
embedded in the application.Many exchange designs have been built using UDP, and many of them
have not worked out. As a result, the use of UDP really should be
treated as designing a new transport. Advice on the use of UDP in
new applications can be found in Unicast UDP
Usage Guidelines for Application Designers.Datagram Transport Layer Security
can be used to prevent eavesdropping, tampering, or message forgery
for applications that run over UDP. Alternatively, UDP can run over
IPsec.TCP is the predominant transport
protocol in use in the Internet. It is "reliable", as the term is
used in protocol design: it delivers data to its peer and provides
acknowledgement to the sender, or it dies trying. It has extensions
for Congestion Control and Explicit Congestion Notification.The user interface for TCP is a byte stream interface - an
application using TCP might "write" to it several times only to have
the data compacted into a common segment and delivered as such to
its peer. For message-stream interfaces, ACSE/ROSE uses the ISO Transport Service on TCP in the application.Transport Layer Security can be
used to prevent eavesdropping, tampering, or message forgery.
Alternatively, TCP can run over IPsec. Additionally, discusses mechanisms similar to SCTP and
DCCP's "cookie" approach that may be used to secure TCP sessions
against flooding attacks.Finally, note that TCP has been the subject of ongoing research
and development since it was written. The Roadmap for TCP Specification Documents
captures this history, and is intended to be a guide to current and
future developers in the area.SCTP is a more recent reliable
transport protocol that can be imagined as a TCP-like context
containing multiple separate and independent message streams (unlike
TCP's byte streams). The design of SCTP includes appropriate
congestion avoidance behavior and resistance to flooding and
masquerade attacks. As it uses a message stream interface, it may
also be more appropriate for the ISO Transport Service than using
RFC 1006/2126 to turn TCP's octet streams into a message
interface.SCTP offers several delivery options. The basic service is
sequential non-duplicated delivery of messages within a stream, for
each stream in use. Since streams are independent, one stream may
pause due to head of line blocking while another stream in the same
session continues to deliver data. In addition, SCTP provides a
mechanism for bypassing the sequenced delivery service. User
messages sent using this mechanism are delivered to the SCTP user as
soon as they are received.SCTP implements a simple "cookie" mechanism intended to limit the
effectiveness of flooding attacks by mutual authentication. This
demonstrates that the application is connected to the same peer, but
does not identify the peer. Mechanisms also exist for Dynamic Address Reconfiguration, enabling
peers to change addresses during the session and yet retain
connectivity. Transport Layer Security
can be used to prevent eavesdropping, tampering, or message forgery.
Alternatively, SCTP can run over IPsec.DCCP is an "unreliable" transport
protocol (e.g., one that does not guarantee message delivery) that
provides bidirectional unicast connections of congestion-controlled
unreliable datagrams. DCCP is suitable for applications that
transfer fairly large amounts of data and that can benefit from
control over the tradeoff between timeliness and reliability.DCCP implements a simple "cookie" mechanism intended to limit the
effectiveness of flooding attacks by mutual authentication. This
demonstrates that the application is connected to the same peer, but
does not identify the peer. Datagram
Transport Layer Security can be used to prevent
eavesdropping, tampering, or message forgery. Alternatively, DCCP
can run over IPsec.In order to facilitate network management and operations, the
Internet Community has defined the Domain
Name System (DNS). Names are
hierarchical: a name like example.com is found registered with a
.com registrar, and within the associated network other names like
baldur.cincinatti.example.com can be defined, with obvious
hierarchy. Security extensions, which allow a registry to sign the
records it contains and in so doing demonstrate their authenticity,
are defined by the DNS Security Extensions .Devices can also optionally update their own DNS record. For
example, a sensor that is using Stateless
Address Autoconfiguration to create an address might want to
associate it with a name using DNS Dynamic
Update or DNS Secure Dynamic
Update.As discussed in , IPv4 address
assignment is generally performed using DHCP. By contrast, points out that IPv6 address assignment can be
accomplished using either autoconfiguration or DHCPv6.
The best argument for the use of autoconfiguration is a large number
of systems that require little more than a random number as an
address; the argument for DHCP is administrative control.There are other parameters that may need to be allocated to hosts
requiring administrative configuration; examples include the
addresses of DNS servers, keys for Secure DNS and Network Time
servers.The Network Time Protocol was originally designed by Dave Mills
of the University of Delaware and CSNET, implementing a temporal
metric in the Fuzzball Routing Protocol and generally coordinating
time experiments. The current versions of the time protocol are the
Network Time Protocol.The IETF has developed two protocols for network management: SNMP
and NETCONF. SNMP is discussed in , and
NETCONF is discussed in .The Simple Network Management Protocol, originally specified in
the late 1980's and having passed through several revisions, is
specified in several documents: An Architecture for Describing Simple
Network Management Protocol (SNMP) Management
FrameworksMessage Processing and
DispatchingSNMP ApplicationsUser-based Security Model (USM) for
SNMP version 3View-based Access Control Model
(VACM)Version 2 of the SNMP Protocol
OperationsTransport MappingsManagement Information Base
(MIB)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.The NETCONF Configuration Protocol is specified in one basic
document, with supporting documents for carrying it over the IPS.
These documents include: NETCONF Configuration
ProtocolUsing the NETCONF Configuration
Protocol over Secure SHell (SSH)Using NETCONF over the Simple Object
Access Protocol (SOAP)Using the NETCONF Protocol over the
Blocks Extensible Exchange Protocol (BEEP)NETCONF Event NotificationsNETCONF over Transport Layer Security
(TLS)Partial Lock Remote Procedure Call
(RPC) for NETCONFNETCONF was developed in response to operator requests for a
common configuration protocol based on ASCII text, unlike ASN.1. In
essence, it carries XML-encoded remote procedure call (RPC) data. In
response to Smart Grid requirements, there is consideration of a
variant of the protocol that could be used for polled and
event-driven management activities, and for both monitoring and
configuration of systems in the field.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.Service discovery protocols are designed for the automatic
configuration and detection of devices, and the services offered by
the discovered devices. In many cases service discovery is performed
by so-called "constrained resource" devices (i.e., those with
limited processing power, memory, and power resources).In general, service discovery is concerned with the resolution
and distribution of host names via multicast DNS and
the automatic location of network services via DHCP, the DNS Service Discovery
(DNS-SD) (part of Apple's Bonjour technology) and the Service Location Protocol (SLP).Resource Discovery is concerned with the discovery of resources
offered by end-points and is extremely important in
machine-to-machine closed-loop applications (i.e., those with no
humans in the loop). The goals of resource discovery protocols
include: Simplicity of creation and maintenance of resourcesCommonly understood semanticsConformance to existing and emerging standardsInternational scope and applicabilityExtensibilityInteroperability among collections and indexing systemsThe Constrained Application
Protocol (CoAP) is being developed in IETF with these goals
in mind. In particular, CoAP is designed for use in constrained
resource networks and for machine-to-machine applications such as
smart energy and building automation. It provides a RESTful transfer
protocol , a built-in resource
discovery protocol, and includes web concepts such as URIs and
content-types. CoAP provides both unicast and multicast resource
discovery and includes the ability to filter on attributes of
resource descriptions. Finally, CoAP resource discovery can also be
used to discover HTTP resources.For simplicity, CoAP makes the assumption that all CoAP servers
listen on the default CoAP port or otherwise have been configured or
discovered using some general service discovery mechanism such as
DNS Service Discovery
(DNS-SD).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" . 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.There are many applications that rely on the IP infrastructure, but
are not properly thought of as part of the IP infrastructure itself.
These applications may be useful in the context of the Smart Grid. The
choices made when constructing a profile of the Internet Profile Suite
may impact how such applications could be used. Some of them, not by
any means an exhaustive list, are discussed here.The Session Initiation
Protocol 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.SIP itself does not choose whether a session is voice or video,
nor does it identify the actual endpoints' IP addresses. The SDP: Session Description Protocol is
intended for those purposes. Within the SDP, which is transported by
SIP, codecs are offered and accepted (or not), the port number and
IP address is decided for where each endpoint wants to receive their
Real-time Transport Protocol (RTP)
packets. The introduction of Network Address Translation (NAT)
technology into the profile, whether IPv4/IPv4, IPv4/IPv as
described in , or IPv6/IPv6,
increases the complexity of SIP/SDP deployment. This is further
discussed in and .The Extensible Messaging and Presence
Protocol (XMPP) is a protocol for streaming Extensible Markup
Language (XML) elements in order to exchange structured information
in close to real time between any two network endpoints. Since XMPP
provides a generalized, extensible framework for exchanging XML
data, it has been proposed as an application structure for
interchange between embedded devices and sensors. It is currently
used for Instant Messaging and
Presence and a wide variety of real-time communication modes.
These include multi-user chat, publish-subscribe, alerts and
notifications, service discovery, multimedia session management,
device configuration, and remote procedure calls. XMPP supports
channel encryption using TLS and
strong authentication (including PKIX certificate authentication)
using SASL. It also makes use of
Unicode-compliant addresses and UTF-8
data exchange for internationalization.XMPP allows for End-to-End Signing and
Object Encryption , access to objects named using Uniform Resource Names (URN) , and the use
of Internationalized Resource Identifiers
(IRIs) and Uniform Resource Identifiers (URIs), and the
presentation of Notifications .Internet calendaring, as implemented in Apple iCal, Microsoft
Outlook and Entourage, and Google Calendar, is specified in Internet Calendaring and Scheduling Core Object
Specification (iCalendar) and is in the process of being
updated to an XML schema in iCalendar XML
Representation Several protocols exist to carry calendar
events, including iCalendar
Transport-Independent Interoperability Protocol (iTIP) , the
Message-Based Interoperability Protocol
(iMIP) , and open source work on the
Atom Publishing Protocol.The Internet is a network of networks in which networks are
interconnected in specific ways and are independently operated. It is
important to note that the underlying Internet architecture puts no
restrictions on the ways that networks are interconnected;
interconnection is a business decision. As such, the Internet
interconnection architecture can be thought of as a "business structure"
for the Internet.Central to the Internet business structure are the networks that
provide connectivity to other networks, called "Transit Networks". These
networks sell bulk bandwidth and routing services to each other and to
other networks as customers. Around the periphery of the transit network
are companies, schools, and other networks that provide services
directly to individuals. These might generally be 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 .A specific example is shown in a traceroute from a home to a nearby
school. Internet connectivity in
passes through The home network,Cox Communications, an Access Network using Cable Modem
technology,TransitRail, a commodity peering service for research and
education (R&E) networks,Corporation for Education Network Initiatives in California
(CENIC), a transit provider for educational networks, andthe 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.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
is entirely within Cisco's internal network.Note that in both cases, the home network uses private address space
while other networks generally use public
address space, and that three middleware technologies are in use here.
These are the uses of a firewall, a Network Address Translator (NAT),
and a Virtual Private Network (VPN).Firewalls are generally sold as and considered by many to be a
security technology. This is based on the fact that a firewall imposes a
border between two administrative domains. Typically, a firewall will be
deployed between a residential, SOHO, or enterprise network and its
access or transit provider. In its essence, a firewall is a data diode,
imposing a policy on what sessions may pass between a protected domain
and the rest of the Internet. Simple policies generally permit sessions
to be originated from the protected network but not from the outside;
more complex policies may permit additional sessions from the outside,
as electronic mail to a mail server or a web session to a web server,
and may prevent certain applications from global access even though they
are originated from the inside.Note that the effectiveness of firewalls remains controversial. While
network managers often insist on deploying firewalls as they impose a
boundary, others point out that their value as a security solution is
debatable. This is because most attacks come from behind the firewall.
In addition, firewalls do not protect against application layer attacks
such as viruses carried in email. Thus, as a security solution,
firewalls are justified as a layer in defense in depth. That is, while
an end system must in the end be responsible for its own security, a
firewall can inhibit or prevent certain kinds of attacks, for example
the consumption of CPU time on a critical server.Key documents describing firewall technology and the issues it poses
include: IP Multicast and FirewallsBenchmarking Terminology for Firewall
PerformanceBehavior of and Requirements for Internet
FirewallsBenchmarking Methodology for Firewall
PerformanceMobile IPv6 and Firewalls: Problem
StatementNAT and Firewall Traversal Issues of Host
Identity Protocol CommunicationNetwork Address Translation is a technology that was developed in
response to ISP behaviors in the mid-1990's; when was published, many ISPs started handing out
single or small numbers of addresses, and edge networks were forced to
translate. In time, this became considered a good thing, or at least not
a bad thing; it amplified the public address space, and it was sold as
if it were a firewall. It of course is not; while traditional dynamic
NATs only translate between internal and external session address/port
tuples during the detected duration of the session, that session state
may exist in the network much longer than it exists on the end system,
and as a result constitutes an attack vector. The design, value, and
limitations of network address translation are described in: IP Network Address Translator Terminology
and ConsiderationsTraditional IP Network Address
TranslatorProtocol Complications with the IP Network
Address TranslatorNetwork Address Translator Friendly
Application Design GuidelinesIAB Considerations for Network Address
TranslationIPsec-Network Address Translation
Compatibility RequirementsNetwork Address Translation Behavioral
Requirements for Unicast UDPState of Peer-to-Peer Communication across
Network Address TranslatorsIP Multicast Requirements for a Network
Address Translator and a Network Address Port TranslatorVirtual 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 , connectivity appears to be
entirely within the edge network although it is in fact across a service
provider's network. Examples include IPsec tunnel-mode encrypted
tunnels, IP-in-IP or GRE tunnels and MPLS
LSPs. .This memo asks the IANA for no new parameters.Note to RFC Editor: This section will have served its purpose if it
correctly tells IANA that no new assignments or registries are required,
or if those assignments or registries are created during the RFC
publication process. From the author"s perspective, it may therefore be
removed upon publication as an RFC at the RFC Editor's discretion.Security is addressed in some detail in and .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. In addition, numerous review comments were made by the
IESG, which have been picked up as well.Interface Message Processor -- Specifications for the
interconnection of a host and a IMP, Report No. 1822Bolt Beranek and Newman Inc.Architectural Styles and the Design of Network-based Software
ArchitecturesUniversity of California, IrvinePOWER SYSTEMS MANAGEMENT AND ASSOCIATED INFORMATION EXCHANGE.
DATA AND COMMUNICATIONS SECURITY -- Part 3: Communication network
and system security Profiles including TCP/IPInternational Electrotechnical Commission Technical
Committee 57IEEE Standard for Local and Metropolitan Area Networks - Port
based Network Access ControlInstitute of Electrical and Electronics
EngineersDOCSIS 3.0 MAC and Upper Layer Protocols Interface
Specification, CM-SP-MULPIv3.0-I10-090529Cisco SystemsSmart Grid Architecture Committee: Conceptual Model White
Paper
http://collaborate.nist.gov/twiki-sggrid/pub/SmartGrid/SGIPConceptualModelDevelopmentSGAC/Smart_Grid_Conceptual_Model_20100420.docWikipedia Article: IEC 61850
http://en.wikipedia.org/wiki/IEC_61850Wikipedia Article: Smart Grid
http://en.wikipedia.org/w/index.php?title=Smart_grid&oldid=415838933This 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. 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.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: How does Demand Response work? Either: The utility presents pricing signals to the home,The utility presents pricing signals individual devices
(e.g., a Pluggable Electric Vehicle),The utility adjusts settings on individual appliances within
the home.How does the utility access meters at the home? The AMI Headend manages the interfaces with the meters,
collecting metering data and passing it on to the appropriate
applications over the Enterprise Bus, orDistributed application support (collectors") might access
and summarize the information; this device might be managed by
the utility or by a service between the utility and its
customers.In implementation, these models are idealized; reality may include
some aspects of each model in specified cases.The examples include: presumes that the HAN, the NAN,
and the utility's network are separate administrative domains and
speak application to application across those domains. repeats the first example, but
presuming that the utility directly accesses appliances within the
HAN from the collector". repeats the first example, but
presuming that the collector directly forwards traffic as a router
in addition to distributed application chores. Note that this case
implies numerous privacy and security concerns and as such is
considered a less likely deployment model.A 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 . In
the late 1970's, the ARPANET switched to X.25 as an interface to the
1822 network. With the deployment of the IEEE 802 series technologies
in the early 1980's, IP was deployed on Ethernet (IEEE 802.3), Token
Ring (IEEE 802.5) and WiFi (IEEE 802.11), as well as Arcnet, serial
lines of various kinds, Frame Relay, and ATM. A key issue in this
evolution was that the applications developed to run on the Internet
use APIs related to the IPS, and as a result require little or no
change to continue to operate in a new link layer architecture or a
mixture of them.The Smart Grid is likely to see a similar evolution over time.
Consider the Home Area Network (HAN) as a readily understandable small
network. At this juncture, technologies proposed for residential
networks include IEEE P1901, various versions of IEEE 802.15.4, and
IEEE 802.11. It is reasonable to expect other technologies to be
developed in the future. As the Zigbee Alliance has learned (and as a
resulted incorporated the IPS in Smart Energy Profile 2.0), there is
significant value in providing a virtual address that is mapped to
interfaces or nodes attached to each of those technologies.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. 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.The HAN can be seen as communicating with two kinds of non-HAN
networks. One is the home LAN, which may in turn be attached to the
Internet, and will generally either derive its prefix from the
upstream ISP or use a self-generated ULA. Another is the utility's
NAN, which through an ESI provides utility connectivity to the HAN;
in this case the HAN will be addressed by a self-generated ULA
(note, however, that in some cases ESI may also provide a prefix via
DHCP). In addition, the HAN will have
link-local addresses that can be used between neighboring nodes. In
general, an HAN will be comprised of both 802.15.4, 802.11 (and
possibly other) networks.The ESI is a node on the user's residential network, and will not
typically provide stateful packet forwarding or firewall services
between the HAN and the utility network(s). In general, the ESI is a
node on the home network; in some cases, the meter may act as the
ESI. However, the ESI must be capable of understanding that most
home networks are not 802.15.4 enabled (rather, they are typically
802.11 networks), and that it must be capable of setting up ad-hoc
networks between various sensors in the home (e.g., between the
meter and say, a thermostat) in the event there aren't other
networks available.In any network, we have a variety of threats and a variety of
possible mitigations. These include, at minimum: 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.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.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.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.In addition,
applications often provide security services of their own. The
fact that I can access a file system, for example, doesn't mean
that I am authorized to access everything in it; the file system
may well prevent my access to some of its contents. Routing
protocols like BGP obsess with the question "what statements
that my peer made am I willing to believe". And monitoring
protocols like SNMP may not be willing to answer every question
they are asked, depending on access configuration.Devices in the HAN want controlled access to the LAN in question
for obvious reasons. In addition, there should be some form of
mutual authentication between devices - the lamp controller will
want to know that the light switch telling it to change state is the
right light switch, for example. The EMS may well want strong
authentication of accesses - the parents may not want the children
changing the settings, and while the utility and the customer are
routinely granted access, other parties (especially parties with
criminal intent) need to be excluded.With the background given in ,
we can now discuss the use of IP (IPv4 or IPv6) in the AMI.In this first model, consider the three domains in to literally be separate administrative domains,
potentially operated by different entities. For example, the NAN could
be a WiMAX network operated by a traditional telecom operator, the
utility's network (including the collector) is its own, and the
residential network is operated by the resident. In this model, while
communications between the collector and the Meter are normal, the
utility has no other access to appliances in the home, and the
collector doesn't directly forward messages from the NAN upstream.In this case, as shown in , it
would make the most sense to design the collector, the Meter, and the
EMS as hosts on the NAN - design them as systems whose applications
can originate and terminate exchanges or sessions in the NAN, but not
forward traffic from or to other devices.In such a configuration, Demand Response has to be performed by
having the EMS accept messages such as price signals from the "pole
top", apply some form of policy, and then orchestrate actions within
the home. Another possibility is to have the EMS communicate with the
ESI located in the meter. If the thermostat has high demand and low
demand (day/night or morning/day/evening/night) settings, Demand
Response might result in it moving to a lower demand setting, and the
EMS might also turn off specified circuits in the home to diminish
lighting.In this scenario, Quality of Service (QoS) issues reportedly arise
when high precedence messages must be sent through the collector to
the home; if the collector is occupied polling the meters or doing
some other task, the application may not yield control of the
processor to the application that services the message. Clearly, this
is either an application or an Operating System problem; applications
need to be designed in a manner that doesn't block high precedence
messages. The collector also needs to use appropriate NAN services, if
they exist, to provide the NAN QoS it needs. For example, if WiMax is
in use, it might use a routine-level service for normal exchanges but
a higher precedence service for these messages.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.In this case, as shown in ,
the Meter, and EMS as hosts on the HAN, and there is a router between
the HAN and the NAN.As one might imagine, there are serious security considerations in
this model. Traffic between the NAN and the residential broadband
network should be filtered, and the issues raised in take on a new level of meaning. One of
the biggest threats may be a legal or at least a public relations
issue; if the utility intentionally disables a circuit in a manner or
at a time that threatens life (the resident's kidney dialysis machine
is on it, or a respirator, for example) the matter might make the
papers. Unauthorized access could be part of juvenile pranks or other
things as well. So one really wants the appliances to only obey
commands under strict authentication/authorization controls.In addition to the QoS issues raised in , 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 , and let other traffic use the Standard
Service Class or other service classes.In this third model, the relationship between the NAN and the HAN
is either as in or ; what is different is that the collector may
be an IP router. In addition to whatever autonomous activities it is
doing, it forwards traffic as an IP router in some cases.As and analogous to , there are
serious security considerations in this model. Traffic being forwarded
should be filtered, and the issues raised in take on a new level of meaning - but
this time at the utility mainframe. Unauthorized access is likely
similar to other financially-motivated attacks that happen in the
Internet, but presumably would be coming from devices in the HAN that
have been co-opted in some way. One really wants the appliances to
only obey commands under strict authentication/authorization
controls.In addition to the QoS issues raised in , 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 , and let other traffic use the Standard
Service Class or other service classes.