tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6272

Informational
Pages: 66
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~internet

Internet Protocols for the Smart Grid

Part 1 of 4, p. 1 to 14
None       Next RFC Part

 


Top       ToC       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       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       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       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       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       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       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       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       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       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       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       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       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       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 RFC Part