Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6272

Internet Protocols for the Smart Grid

Pages: 66
Informational
Part 1 of 4 – Pages 1 to 14
None   None   Next

Top   ToC   RFC6272 - Page 1
Internet Engineering Task Force (IETF)                          F. Baker
Request for Comments: 6272                                      D. Meyer
Category: Informational                                    Cisco Systems
ISSN: 2070-1721                                                June 2011


                 Internet Protocols for the Smart Grid

Abstract

This note identifies the key infrastructure protocols of the Internet Protocol Suite for use in the Smart Grid. The target audience is those people seeking guidance on how to construct an appropriate Internet Protocol Suite profile for the Smart Grid. In practice, such a profile would consist of selecting what is needed for Smart Grid deployment from the picture presented here. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6272. Copyright Notice Copyright (c) 2011 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 described in the Simplified BSD License.
Top   ToC   RFC6272 - Page 2

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 6 2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 6 2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 7 2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . 9 2.1.3.2. Lower-Layer Networks . . . . . . . . . . . . . . . 9 2.1.4. Media Layers: Physical and Link . . . . . . . . . . . 9 2.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 9 2.2.1. Physical and Data Link Layer Security . . . . . . . . 10 2.2.2. Network, Transport, and Application Layer Security . . 11 2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 13 2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 13 2.3.2. Network Management . . . . . . . . . . . . . . . . . . 13 3. Specific Protocols . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Security Toolbox . . . . . . . . . . . . . . . . . . . . . 14 3.1.1. Authentication, Authorization, and Accounting (AAA) . 14 3.1.2. Network Layer Security . . . . . . . . . . . . . . . . 15 3.1.3. Transport Layer Security . . . . . . . . . . . . . . . 16 3.1.4. Application Layer Security . . . . . . . . . . . . . . 17 3.1.5. Secure Shell . . . . . . . . . . . . . . . . . . . . . 18 3.1.6. Key Management Infrastructures . . . . . . . . . . . . 18 3.1.6.1. PKIX . . . . . . . . . . . . . . . . . . . . . . . 18 3.1.6.2. Kerberos . . . . . . . . . . . . . . . . . . . . . 19 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 19 3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 19 3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . . . . 19 3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . 20 3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . 20 3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . 21 3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . 22 3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 22 3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . 22 3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . 23 3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . 23 3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 24 3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . 24 3.2.4.1. Routing Information Protocol . . . . . . . . . . . 24 3.2.4.2. Open Shortest Path First . . . . . . . . . . . . . 24 3.2.4.3. ISO Intermediate System to Intermediate System . . 25 3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . 25 3.2.4.5. Dynamic MANET On-Demand (DYMO) Routing . . . . . . 25 3.2.4.6. Optimized Link State Routing Protocol . . . . . . 26 3.2.4.7. Routing for Low-Power and Lossy Networks . . . . . 26
Top   ToC   RFC6272 - Page 3
       3.2.5.  IPv6 Multicast Forwarding and Routing  . . . . . . . . 27
         3.2.5.1.  Protocol-Independent Multicast Routing . . . . . . 27
       3.2.6.  Adaptation to Lower-Layer Networks and Link Layer
               Protocols  . . . . . . . . . . . . . . . . . . . . . . 28
     3.3.  Transport Layer  . . . . . . . . . . . . . . . . . . . . . 28
       3.3.1.  User Datagram Protocol (UDP) . . . . . . . . . . . . . 28
       3.3.2.  Transmission Control Protocol (TCP)  . . . . . . . . . 29
       3.3.3.  Stream Control Transmission Protocol (SCTP)  . . . . . 29
       3.3.4.  Datagram Congestion Control Protocol (DCCP)  . . . . . 30
     3.4.  Infrastructure . . . . . . . . . . . . . . . . . . . . . . 30
       3.4.1.  Domain Name System . . . . . . . . . . . . . . . . . . 30
       3.4.2.  Dynamic Host Configuration . . . . . . . . . . . . . . 31
       3.4.3.  Network Time . . . . . . . . . . . . . . . . . . . . . 31
     3.5.  Network Management . . . . . . . . . . . . . . . . . . . . 31
       3.5.1.  Simple Network Management Protocol (SNMP)  . . . . . . 31
       3.5.2.  Network Configuration (NETCONF) Protocol . . . . . . . 32
     3.6.  Service and Resource Discovery . . . . . . . . . . . . . . 33
       3.6.1.  Service Discovery  . . . . . . . . . . . . . . . . . . 33
       3.6.2.  Resource Discovery . . . . . . . . . . . . . . . . . . 33
     3.7.  Other Applications . . . . . . . . . . . . . . . . . . . . 34
       3.7.1.  Session Initiation Protocol  . . . . . . . . . . . . . 34
       3.7.2.  Extensible Messaging and Presence Protocol . . . . . . 35
       3.7.3.  Calendaring  . . . . . . . . . . . . . . . . . . . . . 35
   4.  A Simplified View of the Business Architecture . . . . . . . . 35
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 40
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 40
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 41
   Appendix A.  Example: Advanced Metering Infrastructure . . . . . . 58
     A.1.  How to Structure a Network . . . . . . . . . . . . . . . . 59
       A.1.1.  HAN Routing  . . . . . . . . . . . . . . . . . . . . . 62
       A.1.2.  HAN Security . . . . . . . . . . . . . . . . . . . . . 62
     A.2.  Model 1: AMI with Separated Domains  . . . . . . . . . . . 64
     A.3.  Model 2: AMI with Neighborhood Access to the Home  . . . . 65
     A.4.  Model 3: Collector Is an IP Router . . . . . . . . . . . . 66
Top   ToC   RFC6272 - Page 4

1. Introduction

This document provides Smart Grid designers with advice on how to best "profile" the Internet Protocol Suite (IPS) for use in Smart Grids. It provides an overview of the IPS and the key infrastructure protocols that are critical in integrating Smart Grid devices into an IP-based infrastructure. In the words of Wikipedia [SmartGrid]: A Smart Grid is a form of electricity network utilizing digital technology. A Smart Grid delivers electricity from suppliers to consumers using two-way digital communications to control appliances at consumers' homes; this saves energy, reduces costs and increases reliability and transparency. It overlays the ordinary electrical Grid with an information and net metering system, that includes smart meters. Smart Grids are being promoted by many governments as a way of addressing energy independence, global warming and emergency resilience issues. A Smart Grid is made possible by applying sensing, measurement and control devices with two-way communications to electricity production, transmission, distribution and consumption parts of the power Grid that communicate information about Grid condition to system users, operators and automated devices, making it possible to dynamically respond to changes in Grid condition. A Smart Grid includes an intelligent monitoring system that keeps track of all electricity flowing in the system. It also has the capability of integrating renewable electricity such as solar and wind. When power is least expensive the user can allow the smart Grid to turn on selected home appliances such as washing machines or factory processes that can run at arbitrary hours. At peak times it could turn off selected appliances to reduce demand. Other names for a Smart Grid (or for similar proposals) include smart electric or power Grid, intelligent Grid (or intelliGrid), futureGrid, and the more modern interGrid and intraGrid. That description focuses on the implications of Smart Grid technology in the home of a consumer. In fact, data communications technologies of various kinds are used throughout the Grid, to monitor and maintain power generation, transmission, and distribution, as well as the operations and management of the Grid. One can view the Smart Grid as a collection of interconnected computer networks that connects and serves the needs of public and private electrical utilities and their customers.
Top   ToC   RFC6272 - Page 5
   At the time of this writing, there is no single document that can be
   described as comprising an internationally agreed standard for the
   Smart Grid; that is in part the issue being addressed in its
   development.  The nearest approximations are probably the Smart Grid
   Interoperability Panel's Conceptual Model [Model] and documents
   comprising [IEC61850].

   The Internet Protocol Suite (IPS) provides options for numerous
   architectural components.  For example, the IPS provides several
   choices for the traditional transport function between two systems:
   the Transmission Control Protocol (TCP) [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 that 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 Comments
   (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 the time of this writing, RFC 4294 is in the process of being
   updated, in [IPv6-NODE-REQ].

   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:

   o  Section 2 describes the Internet Architecture and its protocol
      suite.

   o  Section 3 outlines a set of protocols that may be useful in Smart
      Grid deployment.  It is not exhaustive.

   o  Finally, Section 4 provides an overview of the business
      architecture embodied in the design and deployment of the IPS.
Top   ToC   RFC6272 - Page 6

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 (ISO-OSI) reference 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.
Top   ToC   RFC6272 - Page 7
                    +---------------------------------+
                    |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) [RFC3411] 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.
Top   ToC   RFC6272 - Page 8

2.1.2. Transport

The term "transport" is perhaps among the most confusing concepts in the communication architecture, to a large extent because people with various backgrounds use it to refer to "the layer below that which I am interested in, which gets my data to my peer". For example, optical network engineers refer to optical fiber and associated electronics as "the transport", while web designers refer to the Hypertext Transfer Protocol (HTTP) [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 it 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 include the delivery of data (either as a stream of messages or a stream of bytes) in a stated sequence with stated expectations regarding delivery rate and loss. For example, TCP will reduce its rate in response to loss, as a congestion control trigger, while DCCP accepts some level of loss if necessary to maintain timeliness.

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.
Top   ToC   RFC6272 - Page 9
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 various network technologies. This is the layer that allows diverse networks such as Ethernet, 802.15.4, etc. to be combined into a uniform IP network. New network technologies can be introduced into the IP Protocol Suite by defining how IP is carried over those technologies, leaving the other layers of the IPS and applications that use those protocol unchanged.
2.1.3.2. Lower-Layer Networks
The network layer can be recursively subdivided as needed. This may be accomplished by tunneling, in which an IP datagram is encapsulated in another IP header for delivery to a decapsulator. IP is frequently carried in Virtual Private Networks (VPNs) across the public Internet using tunneling technologies such as the Tunnel mode of IPsec, IP-in-IP, and Generic Route Encapsulation (GRE) [RFC2784]. In addition, IP is also frequently carried in circuit networks such as MPLS [RFC4364], GMPLS, and ATM. Finally, IP is also carried over wireless networks (IEEE 802.11, 802.15.4, or 802.16) and switched Ethernet (IEEE 802.3) networks.

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 complaining about the security of the Internet is popular, it is important to distinguish between attacks on protocols and attacks on users (e.g., phishing). Attacks on users are largely independent of protocol details, reflecting interface design issues or user education problems, and are out of scope for this document. Security problems with Internet protocols are in scope, of course, and can
Top   ToC   RFC6272 - Page 10
   often be mitigated using existing security features already specified
   for the protocol, or by leveraging the security services offered by
   other IETF protocols.  See the Security Assessment of the
   Transmission Control Protocol (TCP) [TCP-SEC] and the Security
   Assessment of the Internet Protocol version 4 [IP-SEC] for more
   information on TCP and IPv4 issues, respectively.

   These solutions do, however, need to get deployed as well.  The road
   to widespread deployment can sometimes be painful since often
   multiple stakeholders need to take actions.  Experience has shown
   that this takes some time, and very often only happens when the
   incentives are high enough in relation to the costs.

   Furthermore, it is important to stress that available standards are
   important, but the range of security problems is larger than a
   missing standard; many security problems are the result of
   implementation bugs and the result of certain deployment choices.
   While these are outside the realm of standards development, they play
   an important role in the security of the overall system.  Security
   has to be integrated into the entire process.

   The IETF takes security seriously in the design of their protocols
   and architectures; every IETF specification has to have a Security
   Considerations section to document the offered security threats and
   countermeasures.  RFC 3552 [RFC3552] provides recommendations on
   writing such a Security Considerations section.  It also describes
   the classical Internet security threat model and lists common
   security goals.

   In a nutshell, security has to be integrated into every protocol,
   protocol extension, and consequently, every layer of the protocol
   stack to be useful.  We illustrate this also throughout this document
   with references to further security discussions.  Our experience has
   shown that dealing with security as an afterthought does not lead to
   the desired outcome.

   The discussion of security threats and available security mechanisms
   aims to illustrate some of the design aspects that commonly appear.

2.2.1. Physical and Data Link Layer 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
Top   ToC   RFC6272 - Page 11
   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.

   For wireless transmission technologies, eavesdropping on the
   transmitted frames is also typically a concern.  Additionally, those
   operating networks may want to ensure that access to their
   infrastructure is restricted to those who are authenticated and
   authorized (typically called 'network access authentication').  This
   procedure is often offered by security primitives at the data link
   layer.

2.2.2. Network, Transport, and Application Layer Security

At the network, transport, and application layers, it is common to demand a few basic security requirements, commonly referred to as CIA (Confidentiality, Integrity, and Availability): 1. Confidentiality: Protect the transmitted data from unauthorized disclosure (i.e., keep eavesdroppers from learning what was transmitted). For example, for trust in e-commerce applications, credit card transactions are exchanged encrypted between the Web browser and a Web server. 2. Integrity: Protect against unauthorized changes to exchanges, including both intentional change or destruction and accidental change or loss, by ensuring that changes to exchanges are detectable. It has two parts: one for the data and one for the peers. * Peers need to verify that information that appears to be from a trusted peer is really from that peer. This is typically called 'data origin authentication'. * Peers need to validate that the content of the data exchanged is unmodified. The term typically used for this property is 'data integrity'. 3. Availability: Ensure that the resource is accessible by mitigating of denial-of-service attacks.
Top   ToC   RFC6272 - Page 12
   To this we add authenticity, which requires that the communicating
   peers prove that they are in fact who they say they are to each other
   (i.e., mutual authentication).  This generally means knowing "who"
   the peer is, and that they demonstrate the possession of a "secret"
   as part of the security protocol interaction.

   The following three examples aim to illustrate these security
   requirements.

   One common attack against a TCP session is to bombard the session
   with reset messages.  Other attacks against TCP include the "SYN
   flooding" attack, in which an attacker attempts to exhaust the memory
   of the target by creating TCP state.  In particular, the attacker
   attempts to exhaust the target's memory by opening a large number of
   unique TCP connections, each of which is represented by a
   Transmission Control Block (TCB).  The attack is successful if the
   attacker can cause the target to fill its memory with TCBs.

   A number of mechanisms have been developed to deal with these types
   of denial-of-service attacks.  One, "SYN Cookies", delays state
   establishment on the server side to a later phase in the protocol
   exchange.  Another mechanism, specifically targeting the reset attack
   cited above, provides authentication services in TCP itself to ensure
   that fake resets are rejected.

   Another approach would be to offer security protection already at a
   lower layer, such as IPsec (see Section 3.1.2) or TLS (see
   Section 3.1.3), so that a host can identify legitimate messages and
   discard the others, thus mitigating any damage that may have been
   caused by the attack.

   Another common attack involves unauthorized access to resources.  For
   example, an unauthorized party might try to attach to a network.  To
   protect against such an attack, an Internet Service Provider (ISP)
   typically requires network access authentication of new hosts
   demanding access to the network and to the Internet prior to offering
   access.  This exchange typically requires authentication of that
   entity and a check in the ISPs back-end database to determine whether
   corresponding subscriber records exist and are still valid (e.g.,
   active subscription and sufficient credits).

   From the discussion above, establishing a secure communication
   channel is clearly an important concept frequently used to mitigate a
   range of attacks.  Unfortunately, focusing only on channel security
   may not be enough for a given task.  Threat models have evolved and
   even some of the communication endpoints cannot be considered fully
   trustworthy, i.e., even trusted peers may act maliciously.
Top   ToC   RFC6272 - Page 13
   Furthermore, many protocols are more sophisticated in their protocol
   interaction and involve more than two parties in the protocol
   exchange.  Many of the application layer protocols, such as email,
   instant messaging, voice over IP, and presence-based applications,
   fall into this category.  With this class of protocols, secure data,
   such as DNS records, and secure communications with middleware,
   intermediate servers, and supporting applications need to be
   considered as well as the security of the direct communication.  A
   detailed treatment of the security threats and requirements of these
   multi-party protocols is beyond this specification but the interested
   reader is referred to the above-mentioned examples for an
   illustration of what technical mechanisms have been investigated and
   proposed in the past.

2.3. Network Infrastructure

While the following protocols are not critical to the design of a specific system, they are important to running a network, and as such are surveyed here.

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 the DNS. 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 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 has limited support for secure
Top   ToC   RFC6272 - Page 14
   provisioning and configuration, these problems have been solved using
   IP protocols in specifications such as DOCSIS 3.0 [SP-MULPIv3.0].



(page 14 continued on part 2)

Next Section