Network Working Group F. Baker
Internet-Draft D. Meyer
Intended status: Informational Cisco Systems
Expires: February 18, 2011 August 17, 2010
Internet Protocols for the Smart Grid
draft-baker-ietf-core-07
Abstract
This note identifies the key protocols of the Internet Protocol Suite
for use in the Smart Grid. The target audience is those people
seeking guidance on how to construct an appropriate Internet Protocol
Suite profile for the Smart Grid. In practice, such a profile would
consist of selecting what is needed for Smart Grid deployment from
the picture presented here.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 18, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Baker & Meyer Expires February 18, 2011 [Page 1]
Internet-Draft Internet Protocols for the Smart Grid August 2010
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 5
2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 5
2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 6
2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . 8
2.1.3.2. Lower layer networks . . . . . . . . . . . . . . . 8
2.1.4. Media layers: Physical and Link . . . . . . . . . . . 8
2.2. Security issues . . . . . . . . . . . . . . . . . . . . . 8
2.2.1. Physical security . . . . . . . . . . . . . . . . . . 9
2.2.2. Session identification . . . . . . . . . . . . . . . . 9
2.2.3. Confidentiality . . . . . . . . . . . . . . . . . . . 10
2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 11
2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 11
2.3.2. Network Management . . . . . . . . . . . . . . . . . . 11
3. Specific protocols . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Security solutions . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Session identification, authentication,
authorization, and accounting . . . . . . . . . . . . 12
3.1.2. IP Security Architecture (IPsec) . . . . . . . . . . . 12
3.1.3. Transport Layer Security (TLS) . . . . . . . . . . . . 12
3.1.4. Secure/Multipurpose Internet Mail Extensions
(S/MIME) . . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 13
3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . . . . 14
3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . 14
3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . 14
3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . 15
3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . 16
3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 16
3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . 16
3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . 17
3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . 17
3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 18
3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . 18
3.2.4.1. Routing Information Protocol . . . . . . . . . . . 18
3.2.4.2. Open Shortest Path First . . . . . . . . . . . . . 19
3.2.4.3. ISO Intermediate System to Intermediate System . . 19
3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . 19
3.2.4.5. Dynamic MANET On-demand (DYMO) Routing . . . . . . 20
3.2.4.6. Optimized Link State Routing Protocol . . . . . . 20
Baker & Meyer Expires February 18, 2011 [Page 2]
Internet-Draft Internet Protocols for the Smart Grid August 2010
3.2.4.7. Routing for Low power and Lossy Networks . . . . . 20
3.2.5. IPv6 Multicast Forwarding and Routing . . . . . . . . 20
3.2.5.1. Protocol-Independent Multicast Routing . . . . . . 21
3.2.6. Adaptation to lower layer networks and link layer
protocols . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 22
3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 22
3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 22
3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 23
3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 23
3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 24
3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 24
3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 24
3.5. Service and Resource Discovery . . . . . . . . . . . . . . 24
3.5.1. Service Discovery . . . . . . . . . . . . . . . . . . 24
3.5.2. Resource Discovery . . . . . . . . . . . . . . . . 25
3.6. Other Applications . . . . . . . . . . . . . . . . . . . . 26
3.6.1. Network Time . . . . . . . . . . . . . . . . . . . . . 26
3.6.2. Session Initiation Protocol . . . . . . . . . . . . . 26
3.6.3. Calendaring . . . . . . . . . . . . . . . . . . . . . 27
4. A simplified view of the business architecture . . . . . . . . 27
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
6. Security Considerations . . . . . . . . . . . . . . . . . . . 32
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1. Normative References . . . . . . . . . . . . . . . . . . . 32
8.2. Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Baker & Meyer Expires February 18, 2011 [Page 3]
Internet-Draft Internet Protocols for the Smart Grid August 2010
1. Introduction
This document provides Smart Grid designers with advice on how to
best "profile" the Internet Protocol Suite (IPS) for use on with
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.
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) [RFC0793], the Stream Control Transmission Protocol
(SCTP) [RFC4960], and the Datagram Congestion Control Protocol (DCCP)
[RFC4340]. Another option is to select an encapsulation such as the
User Datagram Protocol (UDP) [RFC0768] 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:
o Requirements for Internet Hosts - Communication Layers [RFC1122],
o Requirements for Internet Hosts - Application and Support
[RFC1123],
o Requirements for IP Version 4 Routers [RFC1812], and
o IPv6 Node Requirements [RFC4294],
At this writing, RFC 4294 is in the process of being updated, in
[I-D.ietf-6man-node-req-bis].
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:
Section 2 describes the Internet Architecture and its protocol suite.
Section 3 outlines the set of protocols that will be useful in Smart
Grid deployment. Finally, Section 4 provides an overview of the
business architecture embodied in the design and deployment of the
IPS.
Baker & Meyer Expires February 18, 2011 [Page 4]
Internet-Draft Internet Protocols for the Smart Grid August 2010
2. The Internet Protocol Suite
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.
2.1. Internet Protocol Layers
While Internet architecture uses the definitions and language similar
to language used by the ISO Open System Interconnect Reference (ISO-
OSI) Model (Figure 1), 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.
+--------------------+
| Application Layer |
+--------------------+
| Presentation Layer |
+--------------------+
| Session Layer |
+--------------------+
| Transport layer |
+--------------------+
| Network Layer |
+--------------------+
| Data Link Layer |
+--------------------+
| Physical Layer |
+--------------------+
Figure 1: The ISO OSI Reference Model
The structure of the Internet reference model is shown in Figure 2.
Baker & Meyer Expires February 18, 2011 [Page 5]
Internet-Draft Internet Protocols for the Smart Grid August 2010
+---------------------------------+
|Application |
| +---------------------------+ |
| | Application Protocol | |
| +----------+----------------+ |
| | Encoding | Session Control| |
| +----------+----------------+ |
+---------------------------------+
|Transport |
| +---------------------------+ |
| | Transport layer | |
| +---------------------------+ |
+---------------------------------+
|Network |
| +---------------------------+ |
| | Internet Protocol | |
| +---------------------------+ |
| | Lower network layers | |
| +---------------------------+ |
+---------------------------------+
|Media layers |
| +---------------------------+ |
| | Data Link Layer | |
| +---------------------------+ |
| | Physical Layer | |
| +---------------------------+ |
+---------------------------------+
Figure 2: The Internet Reference Model
2.1.1. Application
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) [RFC1157]
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 Figure 2 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.
Baker & Meyer Expires February 18, 2011 [Page 6]
Internet-Draft Internet Protocols for the Smart Grid August 2010
2.1.2. Transport
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) [RFC2616] (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 [RFC0768], TCP
[RFC0793], DCCP [RFC4340], SCTP [RFC4960], and NORM [RFC5740] 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 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.
2.1.3. Network
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) [RFC3031] 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.
Baker & Meyer Expires February 18, 2011 [Page 7]
Internet-Draft Internet Protocols for the Smart Grid August 2010
2.1.3.1. Internet Protocol
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 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.
2.1.3.2. Lower layer networks
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) [RFC2784]. In
addition, IP is also frequently carried in circuit networks such as
MPLS [RFC4364], 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.
2.1.4. Media layers: Physical and Link
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.
2.2. Security issues
While it is popular to complain about the security of the Internet,
solutions to many Internet security problems already exist but have
not been widely deployed. Internet security solutions attempt to
mitigate a set of known threats 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
Baker & Meyer Expires February 18, 2011 [Page 8]
Internet-Draft Internet Protocols for the Smart Grid August 2010
at every layer, we should expect to find mitigations at every layer.
2.2.1. Physical security
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.
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.
2.2.2. Session identification
At the 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:
1. 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.
2. Verify that information that appears to be from a trusted peer is
in fact from that peer.
3. Validate the content of the data exchanged; it must conform to
the rules of the exchange.
4. Defend the channel against denial of service attacks.
5. Ensure the integrity of the information transported to defend
against modification attacks.
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
Baker & Meyer Expires February 18, 2011 [Page 9]
Internet-Draft Internet Protocols for the Smart Grid August 2010
illustrate the challenges.
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. Experience has shown that by
including information in the transport header or a related protocol
like the IPsec (Section 3.1.2) or TLS (Section 3.1.3), a host can
identify legitimate messages and discard mitigate any damage that may
have been caused by the attack.
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.
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.
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.
2.2.3. Confidentiality
In addition to securing the communications channel and messaging,
there 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 to encrypt the network layer
header.
Baker & Meyer Expires February 18, 2011 [Page 10]
Internet-Draft Internet Protocols for the Smart Grid August 2010
2.3. Network Infrastructure
While these are not critical to the design of a specific system, they
are important to running a network, and as such are surveyed here.
2.3.1. Domain Name System (DNS)
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 that
protocol. DNS and DNSSEC are discussed further in Section 3.4.1.
2.3.2. Network Management
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 [RFC4741], 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 Section 3.4.2. 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 DOCSIS 3.0
[SP-MULPIv3.0].
3. Specific protocols
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, AAA,
transport and network solution dimensions. The following sections
provide guidance for such analyzes.
Baker & Meyer Expires February 18, 2011 [Page 11]
Internet-Draft Internet Protocols for the Smart Grid August 2010
3.1. Security solutions
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.
3.1.1. Session identification, authentication, authorization, and
accounting
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 (Section 3.1.2), which protects
IP datagrams, and Transport Layer Security (Section 3.1.3), which
protects the information which the transport layer delivers.
3.1.2. IP Security Architecture (IPsec)
The Security Architecture for the Internet Protocol (IPsec) [RFC4301]
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 IP Authentication Header (AH) [RFC4302] Encapsulating
Security Payload (ESP) [RFC4303], Internet Key Exchange (IKEv2)
[RFC4306], Cryptographic Algorithms [RFC4307], Cryptographic
Algorithm Implementation Requirements for ESP and AH [RFC4835], and
the use of Advanced Encryption Standard (AES) [RFC4309].
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.
3.1.3. Transport Layer Security (TLS)
Transport Layer Security [RFC5246] and Datagram Transport Layer
Security [RFC4347][I-D.ietf-tls-rfc4347-bis] are mechanisms that
Baker & Meyer Expires February 18, 2011 [Page 12]
Internet-Draft Internet Protocols for the Smart Grid August 2010
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.
When used in conjunction with IEEE 802.1X [IEEE802.1X], EAP-TLS
[RFC5216] is widely considered to offer excellent access security to
a wired or wireless IEEE 802 LAN (IEEE 802.1X in conjunction with
EAP-TLS is the baseline for Zigbee SEP 2.0). Note that one potential
drawback of 802.1X technology is that it requires deployment of
client-side certificates, which is frequently seen as a deployment
barrier.
3.1.4. Secure/Multipurpose Internet Mail Extensions (S/MIME)
The S/MIME [RFC2045] [RFC2046] [RFC2047] [RFC4289] [RFC2049]
[RFC5750] [RFC5751] [RFC4262] 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.
Related work includes the use of digital signatures on XML-encoded
files, which has been jointly standardized by W3C and the IETF
[RFC3275].
3.2. Network Layer
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 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 Section 3.2.1.
3.2.1. IPv4/IPv6 Coexistence Advice
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
Baker & Meyer Expires February 18, 2011 [Page 13]
Internet-Draft Internet Protocols for the Smart Grid August 2010
[I-D.arkko-ipv6-transition-guidelines]. The thoughts in that
document are replicated here.
3.2.1.1. Dual Stack Coexistence
The simplest coexistence approach is to
o provide a network that routes both IPv4 and IPv6,
o ensure that servers similarly support both protocols, and
o require that all new systems 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 [RFC4213].
3.2.1.2. Tunneling Mechanism
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)
[RFC5569].
3.2.1.3. Translation between IPv4 and IPv6 Networks
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:
Baker & Meyer Expires February 18, 2011 [Page 14]
Internet-Draft Internet Protocols for the Smart Grid August 2010
o Framework for IPv4/IPv6 Translation
[I-D.ietf-behave-v6v4-framework]
o IPv6 Addressing of IPv4/IPv6 Translators
[I-D.ietf-behave-address-format]
o DNS extensions [I-D.ietf-behave-dns64]
o IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate]
o Translation from IPv6 Clients to IPv4 Servers
[I-D.ietf-behave-v6v4-xlate-stateful]
As with IPv4/IPv4 Network Address Translation, translation between
IPv4 and IPv6 has limited real world applicability: any application
protocol that carries IP addresses and expects them to be meaningful
to both client and server or to both peers will have trouble when the
addresses are transparently translated. 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 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.
3.2.2. Internet Protocol Version 4
IPv4 [RFC0791] and the Internet Control Message Protocol [RFC0792]
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) [RFC0792], which is a
separate protocol that enables the network to report errors and other
issues to hosts that originate problematic datagrams.
Baker & Meyer Expires February 18, 2011 [Page 15]
Internet-Draft Internet Protocols for the Smart Grid August 2010
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) [RFC1195] and OSPF Version 2
[RFC2328] 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 [RFC2474][RFC2475], which
contains a six bit code point used to select an algorithm (a "per-hop
behavior") to be applied to the datagram.
3.2.2.1. IPv4 Address Allocation and Assignment
IPv4 addresses are administratively assigned, usually using automated
methods, and assigned using the Dynamic Host Configuration Protocol
(DHCP) [RFC2131]. On most interface types, neighboring equipment
identify each other's addresses using Address Resolution Protocol
(ARP) [RFC0826].
3.2.2.2. IPv4 Unicast Routing
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.
IETF specified routing protocols include RIP Version 2 [RFC2453], OSI
IS-IS for IPv4 [RFC1195], OSPF Version 2 [RFC2328], and BGP-4
[RFC4271]. Active research exists in mobile ad hoc routing and other
routing paradigms; these result in new protocols and modified
forwarding paradigms.
3.2.2.3. IPv4 Multicast Forwarding and Routing
IPv4 was originally specified as a unicast (point to point) protocol,
and was extended to support multicast in [RFC1112]. This uses the
Internet Group Management Protocol [RFC3376][RFC4604] to enable
applications to join multicast groups, and for most applications uses
Source-Specific Multicast [RFC4607] for routing and delivery of
multicast messages.
An experiment carried out in IPv4 that is not part of the core
Baker & Meyer Expires February 18, 2011 [Page 16]
Internet-Draft Internet Protocols for the Smart Grid August 2010
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 [RFC2357] 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 [RFC3453], the Negative-
acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol
[RFC5740], and the Selectively Reliable Multicast Protocol (SRMP)
[RFC4410]. These are considered experimental.
3.2.3. Internet Protocol Version 6
IPv6 [RFC2460], with the Internet Control Message Protocol "v6"
[RFC4443], 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
[RFC2474][RFC2475], 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 [RFC4919] RFC
and the Compression Format for IPv6 Datagrams in 6LoWPAN Networks
[I-D.ietf-6lowpan-hc] 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.
3.2.3.1. IPv6 Address Allocation and Assignment
An IPv6 Address [RFC4291] may be administratively assigned using
DHCPv6 [RFC3315] in a manner similar to the way IPv4 addresses are.
Baker & Meyer Expires February 18, 2011 [Page 17]
Internet-Draft Internet Protocols for the Smart Grid August 2010
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 [RFC4862] and [RFC4941].
IPv6 neighbors identify each other's addresses using either Neighbor
Discovery (ND) [RFC4861] or SEcure Neighbor Discovery (SEND)
[RFC3971].
3.2.3.2. IPv6 Routing
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 [RFC2080],
IS-IS for IPv6 [RFC5308], OSPF for IPv6 [RFC5340], and BGP-4 for IPv6
[RFC2545]. 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.
3.2.4. Routing for IPv4 and IPv6
3.2.4.1. Routing Information Protocol
The prototypical routing protocol used in the Internet has probably
been the Routing Information Protocol [RFC1058]. People that use it
today tend to deploy RIPng for IPv6 [RFC2080] and RIP Version 2
[RFC2453]. 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. [RFC1058] provides
guidance to algorithm designers to mitigate these issues.
Baker & Meyer Expires February 18, 2011 [Page 18]
Internet-Draft Internet Protocols for the Smart Grid August 2010
3.2.4.2. Open Shortest Path First
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 [RFC2328] for IPv4, OSPF for IPv6
[RFC5340] for IPv6, and the Support of Address Families in OSPFv3
[RFC5838] to enable [RFC5340] 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.
3.2.4.3. ISO Intermediate System to Intermediate System
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 [RFC1195], and more recently
for routing of IPv6 [RFC5308].
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.
3.2.4.4. Border Gateway Protocol
The Border Gateway Protocol (BGP) [RFC4271] 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 [RFC4760] to BGP allow BGP to carry IPv6 Inter-Domain
Routing [RFC2545], multicast reachability information, and VPN
information, among others.
Considerations that apply with BGP deal with the flexibility and
Baker & Meyer Expires February 18, 2011 [Page 19]
Internet-Draft Internet Protocols for the Smart Grid August 2010
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.
3.2.4.5. Dynamic MANET On-demand (DYMO) Routing
The Mobile Ad Hoc Working Group of the IETF developed, among other
protocols, the Ad hoc On-Demand Distance Vector (AODV) Routing
[RFC3561]. This protocol captured the minds of some in the embedded
devices industry, but experiences 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 updatedDynamic MANET On-demand (DYMO) Routing
[I-D.ietf-manet-dymo].
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.
3.2.4.6. Optimized Link State Routing Protocol
The Optimized Link State Routing Protocol (OLSR) [RFC3626] 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.
3.2.4.7. Routing for Low power and Lossy Networks
The RPL: IPv6 Routing Protocol for Low power and Lossy Networks
[I-D.ietf-roll-rpl] xxx
3.2.5. IPv6 Multicast Forwarding and Routing
IPv6 specifies both unicast and multicast datagram exchange. This
uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710]
[RFC3590] [RFC3810] [RFC4604] to enable applications to join
multicast groups, and for most applications uses Source-Specific
Multicast [RFC4607] for routing and delivery of multicast messages.
Baker & Meyer Expires February 18, 2011 [Page 20]
Internet-Draft Internet Protocols for the Smart Grid August 2010
The mechanisms experimentally developed for reliable multicast in
IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well.
3.2.5.1. Protocol-Independent Multicast Routing
xxx Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised) [RFC3973] xxx Protocol Independent Multicast
- Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601]
xxx Source-Specific Multicast (SSM) [RFC3569] xxx Source-Specific
Protocol Independent Multicast [RFC4608] xxx Authentication and
Confidentiality in Protocol Independent Multicast Sparse Mode
(PIM-SM) Link-Local Messages [RFC5796] xxx
3.2.6. Adaptation to lower layer networks and link layer protocols
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:
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 [RFC0894]. IPv6 does the same
using [RFC2464].
PPP: The IETF has defined a serial line protocol, the Point-to-Point
Protocol (PPP) [RFC1661], that uses HDLC (bit-synchronous or byte
synchronous) framing. The IPv4 adaptation specification is
[RFC1332], and the IPv6 adaptation specification is [RFC5072].
Current use of this protocol is in traditional serial lines,
authentication exchanges in DSL networks using PPP Over Ethernet
(PPPoE) [RFC2516], and in the Digital Signaling Hierarchy
(generally referred to as Packet-on-SONET/SDH) using PPP over
SONET/SDH [RFC2615].
IEEE 802.15.4: The adaptation specification for IPv6 transmission
over IEEE 802.15.4 Networks is [RFC4944].
Numerous other adaptation specifications exist, including ATM, Frame
Relay, X.25, other standardized and proprietary LAN technologies, and
others.
Baker & Meyer Expires February 18, 2011 [Page 21]
Internet-Draft Internet Protocols for the Smart Grid August 2010
3.3. Transport Layer
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.
3.3.1. User Datagram Protocol (UDP)
The User Datagram Protocol [RFC0768] and the Lightweight User
Datagram Protocol [RFC3828] 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 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 Unicast UDP Usage Guidelines
for Application Designers [RFC5405].
Datagram Transport Layer Security [RFC5238] can be used to prevent
eavesdropping, tampering, or message forgery for applications that
run over UDP. Alternatively, UDP can run over IPsec.
3.3.2. Transmission Control Protocol (TCP)
TCP [RFC0793] 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
[RFC5681] and Explicit Congestion Notification [RFC3168].
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 ISO
Transport Service on TCP [RFC1006][RFC2126] in the application.
Transport Layer Security [RFC5246] can be used to prevent
eavesdropping, tampering, or message forgery. Alternatively, TCP can
run over IPsec. Additionally, [RFC4987] 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
Baker & Meyer Expires February 18, 2011 [Page 22]
Internet-Draft Internet Protocols for the Smart Grid August 2010
development since it was written. The End to End research group has
published a Roadmap for TCP Specification Documents [RFC4614] to
capture this history, to guide TCP implementors, and provide context
for TCP researchers.
3.3.3. Stream Control Transmission Protocol (SCTP)
SCTP [RFC4960] 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.
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 [RFC5061], enabling peers to change addresses
during the session and yet retain connectivity. Transport Layer
Security [RFC3436] can be used to prevent eavesdropping, tampering,
or message forgery. Alternatively, SCTP can run over IPsec.
3.3.4. Datagram Congestion Control Protocol (DCCP)
DCCP [RFC4340] 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
[RFC5238] can be used to prevent eavesdropping, tampering, or message
Baker & Meyer Expires February 18, 2011 [Page 23]
Internet-Draft Internet Protocols for the Smart Grid August 2010
forgery. Alternatively, DCCP can run over IPsec.
3.4. Infrastructure
3.4.1. Domain Name System
In order to facilitate network management and operations, the
Internet Community has defined the Domain Name System (DNS)
[RFC1034][RFC1035]. 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 all a
registry to sign the records it contains and as a result demonstrate
their authenticity, are defined by the DNS Security Extensions
[RFC4033][RFC4034][RFC4035].
Devices can also optionally update their own DNS record. For
example, a sensor that is using Stateless Address Autoconfiguration
[RFC4862] to create an address might want to associate it with a name
using DNS Dynamic Update [RFC2136] or DNS Secure Dynamic Update
[RFC3007].
3.4.2. Dynamic Host Configuration
As discussed in Section 3.2.2 and Section 3.2.3, IPv6 address
assignment can be accomplished using either autoconfiguration, DHCP
[RFC2131] or DHCPv6 [RFC3315]. 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
which require administrative configuration; examples include the
addresses of DNS servers, keys for Secure DNS and Network Time
servers.
3.5. Service and Resource Discovery
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.
3.5.1. Service Discovery
Service discovery protocols are designed for the automatic
configuration and detection of devices, and the services offered by
Baker & Meyer Expires February 18, 2011 [Page 24]
Internet-Draft Internet Protocols for the Smart Grid August 2010
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 assignment of
network addresses (perhaps via Stateless Address Autoconfiguration
[RFC4862]), resolution and distribution of hostnames via multicast
DNS [I-D.cheshire-dnsext-multicastdns] and the automatic location of
network services via DHCP (Section 3.4.2), the DNS Service Discovery
(DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part of Apple's Bonjour
technology), and the Service Location Protocol (SLP) [RFC2608].
3.5.2. Resource Discovery
Resource Discovery is concerned with the discovery 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:
Simplicity of creation and maintenance of resources
Commonly understood semantics
Conformance to existing and emerging standards
International scope and applicability
Extensibility
Interoperability among collections and indexing systems
The Constrained Application Protocol (CoAP) [I-D.ietf-core-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 discovery 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) [I-D.cheshire-dnsext-dns-sd].
Resource discovery in CoAP is accomplished through the use of well-
Baker & Meyer Expires February 18, 2011 [Page 25]
Internet-Draft Internet Protocols for the Smart Grid August 2010
known resources which describe the links offered by a CoAP server.
CoAP defines a well-known URI for discovery: "/.well-known/r"
[RFC5785]. 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.
3.6. Other Applications
There are several applications that are widely used but are not
properly thought of as infrastructure.
3.6.1. Network Time
The Network Time Protocol was originally designed by Dave Mills of
the University of Delaware and CSNET, for the purpose of implementing
a temporal metric in the Fuzzball Routing Protocol and generally
coordinating time experiments. The current versions of the time
protocol are the Network Time Protocol [RFC5905].
NTP is currently being updated in [RFC5905].
3.6.2. Session Initiation Protocol
The Session Initiation Protocol
[RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] 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, the
SDP: Session Description Protocol [RFC4566] 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 Real-time Transport Protocol (RTP)
[RFC3550] packets. This part is critical to understand because of
the affect on 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 Session Traversal
Utilities for NAT [RFC5389], the session established by SIP will not
Baker & Meyer Expires February 18, 2011 [Page 26]
Internet-Draft Internet Protocols for the Smart Grid August 2010
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.
3.6.3. Calendaring
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)
[RFC5545] and is in the process of being updated to an XML schema in
iCalendar XML Representation [I-D.daboo-et-al-icalendar-in-xml]
Several protocols exist to carry calendar events, including iCalendar
Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the
Message-Based Interoperability Protocol (iMIP) [RFC2447] , and open
source work on the Atom Publishing Protocol [RFC5023].
4. A simplified view of the business architecture
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
Baker & Meyer Expires February 18, 2011 [Page 27]
Internet-Draft Internet Protocols for the Smart Grid August 2010
part of the "core" of the Internet, and access networks are between
the two. This general structure is depicted in Figure 3.
------ ------
/ \ / \
/--\ / \ / \
|SOHO|---+ Access | |Enterprise|
\--/ | Service | | Network |
/--\ | Provider| | |
|Home|---+ | ------ | |
\--/ \ +---+ +---+ /
\ / / \ \ /
------ | Transit | ------
| Service |
| Provider |
| |
\ /
\ /
------
Figure 3: Conceptual model of Internet businesses
A specific example is shown in a traceroute from a home to a nearby
school. Internet connectivity in Figure 4 passes through
o The home network,
o Cox Communications, an Access Network using Cable Modem
technology,
o TransitRail, a commodity peering service for research and
education (R&E) networks,
o Corporation for Education Network Initiatives in California
(CENIC), a transit provider for educational networks, and
o 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.
Baker & Meyer Expires February 18, 2011 [Page 28]
Internet-Draft Internet Protocols for the Smart Grid August 2010
<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 * * *
Figure 4: Traceroute from residential customer to educational
institution
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 Figure 5 is
entirely within Cisco's internal network.
<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 ...
Figure 5: Traceroute across VPN
Note that in both cases, the home network uses private address space
[RFC1918] while other networks generally use public address space,
and that three middleware technologies are in use here. These are
Baker & Meyer Expires February 18, 2011 [Page 29]
Internet-Draft Internet Protocols for the Smart Grid August 2010
the use 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 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:
o IP Multicast and Firewalls [RFC2588]
o Benchmarking Terminology for Firewall Performance [RFC2647]
o Behavior of and Requirements for Internet Firewalls [RFC2979]
o Benchmarking Methodology for Firewall Performance [RFC3511]
o Mobile IPv6 and Firewalls: Problem Statement [RFC4487]
o NAT and Firewall Traversal Issues of Host Identity Protocol
Communication [RFC5207]
Network Address Translation is a technology that was developed in
response to ISP behaviors in the mid-1990's; when [RFC1918] was
published, many ISPs started handing out single or small numbers of
Baker & Meyer Expires February 18, 2011 [Page 30]
Internet-Draft Internet Protocols for the Smart Grid August 2010
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:
o IP Network Address Translator Terminology and Considerations
[RFC2663]
o Traditional IP Network Address Translator [RFC3022]
o Protocol Complications with the IP Network Address Translator
[RFC3027]
o Network Address Translator Friendly Application Design Guidelines
[RFC3235]
o IAB Considerations for Network Address Translation [RFC3424]
o IPsec-Network Address Translation Compatibility Requirements
[RFC3715]
o Network Address Translation Behavioral Requirements for Unicast
UDP [RFC4787]
o State of Peer-to-Peer Communication across Network Address
Translators [RFC5128]
o IP Multicast Requirements for a Network Address Translator and a
Network Address Port Translator [RFC5135]
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 Figure 5, 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 [RFC3031][RFC3032]. .
5. IANA Considerations
This memo asks the IANA for no new parameters.
Note to RFC Editor: This section will have served its purpose if it
Baker & Meyer Expires February 18, 2011 [Page 31]
Internet-Draft Internet Protocols for the Smart Grid August 2010
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.
6. Security Considerations
Security is addressed in some detail in Section 2.2 and Section 3.1.
7. Acknowledgements
Review comments were made by Andrew Yourtchenko, Ashok Narayanan,
Bernie Volz, Chris Lonvick, Dave McGrew, Dave Oran, David Su, 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, and Toerless Eckert. Dave
McGrew, Vint Cerf, and Ralph Droms suggested text.
8. References
8.1. Normative References
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
8.2. Informative References
[I-D.arkko-ipv6-transition-guidelines]
Arkko, J. and F. Baker, "Guidelines for Using IPv6
Transition Mechanisms",
draft-arkko-ipv6-transition-guidelines-03 (work in
progress), July 2010.
[I-D.cheshire-dnsext-dns-sd]
Cheshire, S. and M. Krochmal, "DNS-Based Service
Baker & Meyer Expires February 18, 2011 [Page 32]
Internet-Draft Internet Protocols for the Smart Grid August 2010
Discovery", draft-cheshire-dnsext-dns-sd-06 (work in
progress), March 2010.
[I-D.cheshire-dnsext-multicastdns]
Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-11 (work in progress),
March 2010.
[I-D.daboo-et-al-icalendar-in-xml]
Daboo, C., Douglass, M., and S. Lees, "xCal: The XML
format for iCalendar",
draft-daboo-et-al-icalendar-in-xml-05 (work in progress),
July 2010.
[I-D.ietf-6lowpan-hc]
Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams in 6LoWPAN Networks", draft-ietf-6lowpan-hc-08
(work in progress), July 2010.
[I-D.ietf-6man-node-req-bis]
Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements RFC 4294-bis",
draft-ietf-6man-node-req-bis-05 (work in progress),
July 2010.
[I-D.ietf-behave-address-format]
Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators",
draft-ietf-behave-address-format-10 (work in progress),
August 2010.
[I-D.ietf-behave-dns64]
Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
"DNS64: DNS extensions for Network Address Translation
from IPv6 Clients to IPv4 Servers",
draft-ietf-behave-dns64-10 (work in progress), July 2010.
[I-D.ietf-behave-v6v4-framework]
Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
IPv4/IPv6 Translation",
draft-ietf-behave-v6v4-framework-10 (work in progress),
August 2010.
[I-D.ietf-behave-v6v4-xlate]
Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", draft-ietf-behave-v6v4-xlate-21 (work in
progress), August 2010.
Baker & Meyer Expires February 18, 2011 [Page 33]
Internet-Draft Internet Protocols for the Smart Grid August 2010
[I-D.ietf-behave-v6v4-xlate-stateful]
Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers",
draft-ietf-behave-v6v4-xlate-stateful-12 (work in
progress), July 2010.
[I-D.ietf-core-coap]
Shelby, Z., Frank, B., and D. Sturek, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-01
(work in progress), July 2010.
[I-D.ietf-manet-dymo]
Chakeres, I. and C. Perkins, "Dynamic MANET On-demand
(DYMO) Routing", draft-ietf-manet-dymo-21 (work in
progress), July 2010.
[I-D.ietf-roll-rpl]
Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing
Protocol for Low power and Lossy Networks",
draft-ietf-roll-rpl-11 (work in progress), July 2010.
[I-D.ietf-tls-rfc4347-bis]
Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security version 1.2", draft-ietf-tls-rfc4347-bis-04 (work
in progress), July 2010.
[IEEE802.1X]
Institute of Electrical and Electronics Engineers, "IEEE
Standard for Local and Metropolitan Area Networks - Port
based Network Access Control", IEEE Standard 802.1X-2010,
February 2010.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
converting network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware", STD 37,
Baker & Meyer Expires February 18, 2011 [Page 34]
Internet-Draft Internet Protocols for the Smart Grid August 2010
RFC 826, November 1982.
[RFC0894] Hornig, C., "Standard for the transmission of IP datagrams
over Ethernet networks", STD 41, RFC 894, April 1984.
[RFC1006] Rose, M. and D. Cass, "ISO transport services on top of
the TCP: Version 3", STD 35, RFC 1006, May 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058,
June 1988.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin,
"Simple Network Management Protocol (SNMP)", STD 15,
RFC 1157, May 1990.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol
(IPCP)", RFC 1332, May 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996.
Baker & Meyer Expires February 18, 2011 [Page 35]
Internet-Draft Internet Protocols for the Smart Grid August 2010
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080,
January 1997.
[RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on top
of TCP (ITOT)", RFC 2126, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF
Criteria for Evaluating Reliable Multicast Transport and
Application Protocols", RFC 2357, June 1998.
[RFC2447] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar
Message-Based Interoperability Protocol (iMIP)", RFC 2447,
November 1998.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, February 1999.
Baker & Meyer Expires February 18, 2011 [Page 36]
Internet-Draft Internet Protocols for the Smart Grid August 2010
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol
Extensions for IPv6 Inter-Domain Routing", RFC 2545,
March 1999.
[RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588,
May 1999.
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608,
June 1999.
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615,
June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2647] Newman, D., "Benchmarking Terminology for Firewall
Performance", RFC 2647, August 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022,
January 2001.
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications
with the IP Network Address Translator", RFC 3027,
January 2001.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Baker & Meyer Expires February 18, 2011 [Page 37]
Internet-Draft Internet Protocols for the Smart Grid August 2010
Label Switching Architecture", RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup
Language) XML-Signature Syntax and Processing", RFC 3275,
March 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002.
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Layer Security over Stream Control Transmission Protocol",
RFC 3436, December 2002.
[RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley,
M., and J. Crowcroft, "The Use of Forward Error Correction
(FEC) in Reliable Multicast", RFC 3453, December 2002.
[RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. Martin,
"Benchmarking Methodology for Firewall Performance",
RFC 3511, April 2003.
Baker & Meyer Expires February 18, 2011 [Page 38]
Internet-Draft Internet Protocols for the Smart Grid August 2010
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-
Demand Distance Vector (AODV) Routing", RFC 3561,
July 2003.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC3590] Haberman, B., "Source Address Selection for the Multicast
Listener Discovery (MLD) Protocol", RFC 3590,
September 2003.
[RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing
Protocol (OLSR)", RFC 3626, October 2003.
[RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation
(NAT) Compatibility Requirements", RFC 3715, March 2004.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and
G. Fairhurst, "The Lightweight User Datagram Protocol
(UDP-Lite)", RFC 3828, July 2004.
[RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES)
Requirement for the Session Initiation Protocol (SIP)",
RFC 3853, July 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol
Independent Multicast - Dense Mode (PIM-DM): Protocol
Specification (Revised)", RFC 3973, January 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Baker & Meyer Expires February 18, 2011 [Page 39]
Internet-Draft Internet Protocols for the Smart Grid August 2010
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4262] Santesson, S., "X.509 Certificate Extension for Secure/
Multipurpose Internet Mail Extensions (S/MIME)
Capabilities", RFC 4262, December 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures",
BCP 13, RFC 4289, December 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the
Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
December 2005.
[RFC4309] Housley, R., "Using Advanced Encryption Standard (AES) CCM
Mode with IPsec Encapsulating Security Payload (ESP)",
RFC 4309, December 2005.
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the
Session Initiation Protocol's (SIP) Non-INVITE
Transaction", RFC 4320, January 2006.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Baker & Meyer Expires February 18, 2011 [Page 40]
Internet-Draft Internet Protocols for the Smart Grid August 2010
Security", RFC 4347, April 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4410] Pullen, M., Zhao, F., and D. Cohen, "Selectively Reliable
Multicast Protocol (SRMP)", RFC 4410, February 2006.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile
IPv6 and Firewalls: Problem Statement", RFC 4487,
May 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source-
Specific Multicast", RFC 4604, August 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific
Protocol Independent Multicast in 232/8", BCP 120,
RFC 4608, August 2006.
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap
for Transmission Control Protocol (TCP) Specification
Documents", RFC 4614, September 2006.
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741,
December 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
Baker & Meyer Expires February 18, 2011 [Page 41]
Internet-Draft Internet Protocols for the Smart Grid August 2010
RFC 4787, January 2007.
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4835, April 2007.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
Protocol (SIP)", RFC 4916, June 2007.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, August 2007.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007.
[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing
Protocol", RFC 5023, October 2007.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061,
September 2007.
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007.
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-
Peer (P2P) Communication across Network Address
Baker & Meyer Expires February 18, 2011 [Page 42]
Internet-Draft Internet Protocols for the Smart Grid August 2010
Translators (NATs)", RFC 5128, March 2008.
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a
Network Address Translator (NAT) and a Network Address
Port Translator (NAPT)", BCP 135, RFC 5135, February 2008.
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and
Firewall Traversal Issues of Host Identity Protocol (HIP)
Communication", RFC 5207, April 2008.
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS
Authentication Protocol", RFC 5216, March 2008.
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over
the Datagram Congestion Control Protocol (DCCP)",
RFC 5238, May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
October 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen,
"Addressing an Amplification Vulnerability in Session
Initiation Protocol (SIP) Forking Proxies", RFC 5393,
December 2008.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling
Core Object Specification (iCalendar)", RFC 5545,
September 2009.
[RFC5546] Daboo, C., "iCalendar Transport-Independent
Interoperability Protocol (iTIP)", RFC 5546,
December 2009.
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4
Baker & Meyer Expires February 18, 2011 [Page 43]
Internet-Draft Internet Protocols for the Smart Grid August 2010
Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5621] Camarillo, G., "Message Body Handling in the Session
Initiation Protocol (SIP)", RFC 5621, September 2009.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009.
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker,
"NACK-Oriented Reliable Multicast (NORM) Transport
Protocol", RFC 5740, November 2009.
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Certificate
Handling", RFC 5750, January 2010.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785,
April 2010.
[RFC5796] Atwood, W., Islam, S., and M. Siami, "Authentication and
Confidentiality in Protocol Independent Multicast Sparse
Mode (PIM-SM) Link-Local Messages", RFC 5796, March 2010.
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3",
RFC 5838, April 2010.
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010.
[SP-MULPIv3.0]
CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols
Interface Specification, CM-SP-MULPIv3.0-I10-090529",
May 2009.
Baker & Meyer Expires February 18, 2011 [Page 44]
Internet-Draft Internet Protocols for the Smart Grid August 2010
Authors' Addresses
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
Email: fred@cisco.com
David Meyer
Cisco Systems
Eugene, Oregon 97403
USA
Email: dmm@cisco.com
Baker & Meyer Expires February 18, 2011 [Page 45]
