idnits 2.17.1 draft-baker-ietf-core-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 11 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 22, 2011) is 4753 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4294 (Obsoleted by RFC 6434) == Outdated reference: A later version (-11) exists of draft-cheshire-dnsext-dns-sd-10 == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-14 == Outdated reference: A later version (-11) exists of draft-daboo-et-al-icalendar-in-xml-08 == Outdated reference: A later version (-11) exists of draft-ietf-6man-node-req-bis-08 == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-05 == Outdated reference: A later version (-34) exists of draft-ietf-dime-rfc3588bis-26 == Outdated reference: A later version (-26) exists of draft-ietf-manet-dymo-21 == Outdated reference: A later version (-31) exists of draft-ietf-oauth-v2-15 == Outdated reference: A later version (-03) exists of draft-ietf-tcpm-tcp-security-02 == Outdated reference: A later version (-06) exists of draft-ietf-tls-rfc4347-bis-05 == Outdated reference: A later version (-08) exists of draft-mcgrew-tls-aes-ccm-ecc-01 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3511 (Obsoleted by RFC 9411) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4307 (Obsoleted by RFC 8247) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4492 (Obsoleted by RFC 8422) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) -- Obsolete informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) -- Obsolete informational reference (is this intentional?): RFC 4742 (Obsoleted by RFC 6242) -- Obsolete informational reference (is this intentional?): RFC 4835 (Obsoleted by RFC 7321) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) -- Obsolete informational reference (is this intentional?): RFC 5430 (Obsoleted by RFC 6460) -- Obsolete informational reference (is this intentional?): RFC 5539 (Obsoleted by RFC 7589) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 5785 (Obsoleted by RFC 8615) -- Obsolete informational reference (is this intentional?): RFC 5849 (Obsoleted by RFC 6749) -- Obsolete informational reference (is this intentional?): RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft D. Meyer 4 Intended status: Informational Cisco Systems 5 Expires: October 24, 2011 April 22, 2011 7 Internet Protocols for the Smart Grid 8 draft-baker-ietf-core-15 10 Abstract 12 This note identifies the key infrastructure protocols of the Internet 13 Protocol Suite for use in the Smart Grid. The target audience is 14 those people seeking guidance on how to construct an appropriate 15 Internet Protocol Suite profile for the Smart Grid. In practice, 16 such a profile would consist of selecting what is needed for Smart 17 Grid deployment from the picture presented here. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on October 24, 2011. 36 Copyright Notice 38 Copyright (c) 2011 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 6 55 2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 6 56 2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 7 57 2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 8 58 2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 8 59 2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . 9 60 2.1.3.2. Lower layer networks . . . . . . . . . . . . . . . 9 61 2.1.4. Media layers: Physical and Link . . . . . . . . . . . 9 62 2.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 9 63 2.2.1. Physical and Data Link Layer Security . . . . . . . . 10 64 2.2.2. Network, Transport, and Application Layer Security . . 11 65 2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 13 66 2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 13 67 2.3.2. Network Management . . . . . . . . . . . . . . . . . . 13 68 3. Specific protocols . . . . . . . . . . . . . . . . . . . . . . 14 69 3.1. Security Toolbox . . . . . . . . . . . . . . . . . . . . . 14 70 3.1.1. Authentication, Authorization, and Accounting (AAA) . 14 71 3.1.2. Network Layer Security . . . . . . . . . . . . . . . . 15 72 3.1.3. Transport Layer Security . . . . . . . . . . . . . . . 16 73 3.1.4. Application Layer Security . . . . . . . . . . . . . . 17 74 3.1.5. Secure Shell . . . . . . . . . . . . . . . . . . . . . 17 75 3.1.6. Key Management Infrastructures . . . . . . . . . . . . 18 76 3.1.6.1. PKIX . . . . . . . . . . . . . . . . . . . . . . . 18 77 3.1.6.2. Kerberos . . . . . . . . . . . . . . . . . . . . . 18 78 3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 19 79 3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 19 80 3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . . . . 19 81 3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . 20 82 3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . 20 83 3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . 21 84 3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . 22 85 3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 22 86 3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . 22 87 3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . 23 88 3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . 23 89 3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 23 90 3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . 24 91 3.2.4.1. Routing Information Protocol . . . . . . . . . . . 24 92 3.2.4.2. Open Shortest Path First . . . . . . . . . . . . . 24 93 3.2.4.3. ISO Intermediate System to Intermediate System . . 25 94 3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . 25 95 3.2.4.5. Dynamic MANET On-demand (DYMO) Routing . . . . . . 25 96 3.2.4.6. Optimized Link State Routing Protocol . . . . . . 26 97 3.2.4.7. Routing for Low power and Lossy Networks . . . . . 26 98 3.2.5. IPv6 Multicast Forwarding and Routing . . . . . . . . 26 99 3.2.5.1. Protocol-Independent Multicast Routing . . . . . . 27 100 3.2.6. Adaptation to lower layer networks and link layer 101 protocols . . . . . . . . . . . . . . . . . . . . . . 27 102 3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 28 103 3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 28 104 3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 29 105 3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 29 106 3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 30 107 3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 30 108 3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 30 109 3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 30 110 3.4.3. Network Time . . . . . . . . . . . . . . . . . . . . . 31 111 3.5. Network Management . . . . . . . . . . . . . . . . . . . . 31 112 3.5.1. Simple Network Management Protocol (SNMP) . . . . . . 31 113 3.5.2. Network Configuration (NETCONF) Protocol . . . . . . . 32 114 3.6. Service and Resource Discovery . . . . . . . . . . . . . . 32 115 3.6.1. Service Discovery . . . . . . . . . . . . . . . . . . 33 116 3.6.2. Resource Discovery . . . . . . . . . . . . . . . . . . 33 117 3.7. Other Applications . . . . . . . . . . . . . . . . . . . . 34 118 3.7.1. Session Initiation Protocol . . . . . . . . . . . . . 34 119 3.7.2. Extensible Messaging and Presence Protocol . . . . . . 35 120 3.7.3. Calendaring . . . . . . . . . . . . . . . . . . . . . 35 121 4. A simplified view of the business architecture . . . . . . . . 35 122 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 123 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 124 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 125 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 126 8.1. Normative References . . . . . . . . . . . . . . . . . . . 41 127 8.2. Informative References . . . . . . . . . . . . . . . . . . 41 128 Appendix A. Example: Advanced Metering Infrastructure . . . . . . 58 129 A.1. How to structure a network . . . . . . . . . . . . . . . . 59 130 A.1.1. HAN Routing . . . . . . . . . . . . . . . . . . . . . 62 131 A.1.2. HAN Security . . . . . . . . . . . . . . . . . . . . . 62 132 A.2. Model 1: AMI with separated domains . . . . . . . . . . . 64 133 A.3. Model 2: AMI with neighborhood access to the home . . . . 64 134 A.4. Model 3: Collector is an IP router . . . . . . . . . . . . 65 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 137 1. Introduction 139 This document provides Smart Grid designers with advice on how to 140 best "profile" the Internet Protocol Suite (IPS) for use in Smart 141 Grids. It provides an overview of the IPS and the key infrastructure 142 protocols that are critical in integrating Smart Grid devices into an 143 IP-based infrastructure. 145 In the words of the Wikipedia [SmartGrid], 147 A Smart Grid is a form of electricity network utilizing digital 148 technology. A Smart Grid delivers electricity from suppliers to 149 consumers using two-way digital communications to control 150 appliances at consumers' homes; this saves energy, reduces costs 151 and increases reliability and transparency. It overlays the 152 ordinary electrical Grid with an information and net metering 153 system, that includes smart meters. Smart Grids are being 154 promoted by many governments as a way of addressing energy 155 independence, global warming and emergency resilience issues. 157 A Smart Grid is made possible by applying sensing, measurement and 158 control devices with two-way communications to electricity 159 production, transmission, distribution and consumption parts of 160 the power Grid that communicate information about Grid condition 161 to system users, operators and automated devices, making it 162 possible to dynamically respond to changes in Grid condition. 164 A Smart Grid includes an intelligent monitoring system that keeps 165 track of all electricity flowing in the system. It also has the 166 capability of integrating renewable electricity such as solar and 167 wind. When power is least expensive the user can allow the smart 168 Grid to turn on selected home appliances such as washing machines 169 or factory processes that can run at arbitrary hours. At peak 170 times it could turn off selected appliances to reduce demand. 172 Other names for a Smart Grid (or for similar proposals) include 173 smart electric or power Grid, intelligent Grid (or intelliGrid), 174 futureGrid, and the more modern interGrid and intraGrid. 176 That description focuses on the implications of Smart Grid technology 177 in the home of a consumer. In fact, data communications technologies 178 of various kinds are used throughout the Grid, to monitor and 179 maintain power generation, transmission, and distribution, as well as 180 the operations and management of the Grid. One can view the Smart 181 Grid as a collection of interconnected computer networks that 182 connects and serves the needs of public and private electrical 183 utilities and their customers. 185 At this writing, there is no single document that can be described as 186 comprising an internationally agreed standard for the Smart Grid; 187 that is in part the issue being addressed in its development. The 188 nearest approximations are probably the Smart Grid Interoperability 189 Panel's Conceptual Model [Model] and documents comprising [IEC61850]. 191 The Internet Protocol Suite (IPS) provides options for numerous 192 architectural components. For example, the IPS provides several 193 choices for the traditional transport function between two systems: 194 the Transmission Control Protocol (TCP) [RFC0793], the Stream Control 195 Transmission Protocol (SCTP) [RFC4960], and the Datagram Congestion 196 Control Protocol (DCCP) [RFC4340]. Another option is to select an 197 encapsulation such as the User Datagram Protocol (UDP) [RFC0768] 198 which essentially allows an application to implement its own 199 transport service. In practice, a designer will pick a transport 200 protocol which is appropriate to the problem being solved. 202 The IPS is standardized by the Internet Engineering Task Force 203 (IETF). IETF protocols are documented in the Request for Comment 204 (RFC) series. Several RFCs have been written describing how the IPS 205 should be implemented. These include: 207 o Requirements for Internet Hosts - Communication Layers [RFC1122], 209 o Requirements for Internet Hosts - Application and Support 210 [RFC1123], 212 o Requirements for IP Version 4 Routers [RFC1812], and 214 o IPv6 Node Requirements [RFC4294], 216 At this writing, RFC 4294 is in the process of being updated, in 217 [I-D.ietf-6man-node-req-bis]. 219 This document is intended to provide Smart Grid architects and 220 designers with a compendium of relevant RFCs (and to some extent, 221 Internet Drafts), and is organized as an annotated list of RFCs. To 222 that end, the remainder of this document is organized as follows: 224 o Section 2 describes the Internet Architecture and its protocol 225 suite. 227 o Section 3 outlines a set of protocols that may be useful in Smart 228 Grid deployment. It is not exhaustive. 230 o Finally, Section 4 provides an overview of the business 231 architecture embodied in the design and deployment of the IPS. 233 2. The Internet Protocol Suite 235 Before enumerating the list of Internet protocols relevant to Smart 236 Grid, we discuss the layered architecture of the IPS, the functions 237 of the various layers, and their associated protocols. 239 2.1. Internet Protocol Layers 241 While Internet architecture uses the definitions and language similar 242 to language used by the ISO Open System Interconnect Reference (ISO- 243 OSI) Model (Figure 1), it actually predates that model. As a result, 244 there is some skew in terminology. For example, the ISO-OSI model 245 uses "end system" while the Internet architecture uses "host". 246 Similarly, an "intermediate system" in the ISO-OSI model is called an 247 "internet gateway" or "router" in Internet parlance. Notwithstanding 248 these differences, the fundamental concepts are largely the same. 250 +--------------------+ 251 | Application Layer | 252 +--------------------+ 253 | Presentation Layer | 254 +--------------------+ 255 | Session Layer | 256 +--------------------+ 257 | Transport layer | 258 +--------------------+ 259 | Network Layer | 260 +--------------------+ 261 | Data Link Layer | 262 +--------------------+ 263 | Physical Layer | 264 +--------------------+ 266 Figure 1: The ISO OSI Reference Model 268 The structure of the Internet reference model is shown in Figure 2. 270 +---------------------------------+ 271 |Application | 272 | +---------------------------+ | 273 | | Application Protocol | | 274 | +----------+----------------+ | 275 | | Encoding | Session Control| | 276 | +----------+----------------+ | 277 +---------------------------------+ 278 |Transport | 279 | +---------------------------+ | 280 | | Transport layer | | 281 | +---------------------------+ | 282 +---------------------------------+ 283 |Network | 284 | +---------------------------+ | 285 | | Internet Protocol | | 286 | +---------------------------+ | 287 | | Lower network layers | | 288 | +---------------------------+ | 289 +---------------------------------+ 290 |Media layers | 291 | +---------------------------+ | 292 | | Data Link Layer | | 293 | +---------------------------+ | 294 | | Physical Layer | | 295 | +---------------------------+ | 296 +---------------------------------+ 298 Figure 2: The Internet Reference Model 300 2.1.1. Application 302 In the Internet model, the Application, Presentation, and Session 303 layers are compressed into a single entity called "the application". 304 For example, the Simple Network Management Protocol (SNMP) [RFC3411] 305 describes an application that encodes its data in an ASN.1 profile 306 and engages in a session to manage a network element. The point here 307 is that in the Internet the distinction between these layers exists 308 but is not highlighted. Further, note that in Figure 2 these 309 functions are not necessarily cleanly layered: the fact that an 310 application protocol encodes its data in some way and that it manages 311 sessions in some way doesn't imply a hierarchy between those 312 processes. Rather, the application views encoding, session 313 management, and a variety of other services as a tool set that it 314 uses while doing its work. 316 2.1.2. Transport 318 The term "transport" is perhaps among the most confusing concepts in 319 the communication architecture, to a large extent because people with 320 various backgrounds use it to refer to "the layer below that which I 321 am interested in, which gets my data to my peer". For example, 322 optical network engineers refer to optical fiber and associated 323 electronics as "the transport", while web designers refer to the 324 Hypertext Transfer Protocol (HTTP) [RFC2616] (an application layer 325 protocol) as "the transport". 327 In the Internet protocol stack, the "transport" is the lowest 328 protocol layer that travels end-to-end unmodified, and is responsible 329 for end-to-end data delivery services. In the Internet the transport 330 layer is the layer above the network layer. Transport layer 331 protocols have a single minimum requirement: the ability to multiplex 332 several applications on one IP address. UDP [RFC0768], TCP 333 [RFC0793], DCCP [RFC4340], SCTP [RFC4960], and NORM [RFC5740] each 334 accomplish this using a pair of port numbers, one for the sender and 335 one for the receiver. A port number identifies an application 336 instance, which might be a general "listener" that peers or clients 337 may open sessions with, or a specific correspondent with such a 338 "listener". The session identification in an IP datagram is often 339 called the "five-tuple", and consists of the source and destination 340 IP addresses, the source and destination ports, and an identifier for 341 the transport protocol in use. 343 In addition, the responsibilities of a specific transport layer 344 protocol typically include the delivery of data (either as a stream 345 of messages or a stream of bytes) in a stated sequence with stated 346 expectations regarding delivery rate and loss. For example, TCP will 347 reduce its rate in response to loss, as a congestion control trigger, 348 while DCCP accepts some level of loss if necessary to maintain 349 timeliness. 351 2.1.3. Network 353 The main function of the network layer is to identify a remote 354 destination and deliver data to it. In connection-oriented networks 355 such as Multi-protocol Label Switching (MPLS) [RFC3031] or 356 Asynchronous Transfer Mode (ATM), a path is set up once, and data is 357 delivered through it. In connectionless networks such as Ethernet 358 and IP, data is delivered as datagrams. Each datagram contains both 359 the source and destination network layer addresses, and the network 360 is responsible for delivering it. In the Internet Protocol Suite, 361 the Internet Protocol is the network that runs end to end. It may be 362 encapsulated over other LAN and WAN technologies, including both IP 363 networks and networks of other types. 365 2.1.3.1. Internet Protocol 367 IPv4 and IPv6, each of which is called the Internet Protocol, are 368 connectionless ("datagram") architectures. They are designed as 369 common elements that interconnect network elements across a network 370 of lower layer networks. In addition to the basic service of 371 identifying a datagram's source and destination, they offer services 372 to fragment and reassemble datagrams when necessary, assist in 373 diagnosis of network failures, and carry additional information 374 necessary in special cases. 376 The Internet layer provides a uniform network abstraction network 377 that hides the differences between various network technologies. 378 This is the layer that allows diverse networks such as Ethernet, 379 802.15.4, etc. to be combined into a uniform IP network. New network 380 technologies can be introduced into the IP Protocol Suite by defining 381 how IP is carried over those technologies, leaving the other layers 382 of the IPS and applications that use those protocol unchanged. 384 2.1.3.2. Lower layer networks 386 The network layer can be recursively subdivided as needed. This may 387 be accomplished by tunneling, in which an IP datagram is encapsulated 388 in another IP header for delivery to a decapsulator. IP is 389 frequently carried in Virtual Private Networks (VPNs) across the 390 public Internet using tunneling technologies such as the Tunnel mode 391 of IPsec, IP-in-IP, and Generic Route Encapsulation (GRE) [RFC2784]. 392 In addition, IP is also frequently carried in circuit networks such 393 as MPLS [RFC4364], GMPLS, and ATM. Finally, IP is also carried over 394 wireless networks (IEEE 802.11, 802.15.4, or 802.16) and switched 395 Ethernet (IEEE 802.3) networks. 397 2.1.4. Media layers: Physical and Link 399 At the lowest layer of the IP architecture, data is encoded in 400 messages and transmitted over the physical media. While the IETF 401 specifies algorithms for carrying IPv4 and IPv6 various media types, 402 it rarely actually defines the media - it happily uses specifications 403 from IEEE, ITU, and other sources. 405 2.2. Security Issues 407 While it is popular to complain about the security of the Internet, 408 it is important to distinguish between attacks on protocols and 409 attacks on user (e.g., phishing). Attacks on users are largely 410 independent of protocol details, reflecting interface design issues 411 or user education problems, and are out of scope for this document. 412 Security problems with Internet protocols are in scope, of course, 413 and can often be mitigated using existing security features already 414 specified for the protocol, or by leveraging the security services 415 offered by other IETF protocols. See the Security Assessment of the 416 Transmission Control Protocol (TCP) [I-D.ietf-tcpm-tcp-security] and 417 the Security Assessment of the Internet Protocol version 4 418 [I-D.ietf-opsec-ip-security] for more information on TCP and IPv4 419 issues, respectively. 421 These solutions do, however, need to get deployed as well. The road 422 to widespread deployment can sometimes be painful since often 423 multiple stakeholders need to take actions. Experience has shown 424 that this takes some time, and very often only happens when the 425 incentives are high enough in relation to the costs. 427 Furthermore, it is important to stress that available standards are 428 important but the range of security problems is larger than a missing 429 standard; many security problems are the result of implementation 430 bugs and the result of certain deployment choices. While these are 431 outside the realm of standards development, they play an important 432 role in the security of the overall system. Security has to be 433 integrated into the entire process. 435 The IETF takes security seriously in the design of their protocols 436 and architectures; every IETF specification has to have a security 437 consideration section to document the offered security threats and 438 countermeasures. RFC 3522 [RFC3522] provides recommendations writing 439 such a security consideration section. It also describes the 440 classical Internet security threat model and lists common security 441 goals. 443 In a nutshell, security has to be integrated into every protocol, 444 protocol extension, and consequently, every layer of the protocol 445 stack to be useful. We illustrate this also throughout this document 446 with references to further security discussions. Our experience has 447 shown that dealing with it as an afterthought does not lead to the 448 desired outcome. 450 The discussion of security threats and available security mechanisms 451 aims to illustrate some of the design aspects that commonly appear. 453 2.2.1. Physical and Data Link Layer Security 455 At the physical and data link layers, threats generally center on 456 physical attacks on the network - the effects of backhoes, 457 deterioration of physical media, and various kinds of environmental 458 noise. Radio-based networks are subject to signal fade due to 459 distance, interference, and environmental factors; it is widely noted 460 that IEEE 802.15.4 networks frequently place a metal ground plate 461 between the meter and the device that manages it. Fiber was at one 462 time deployed because it was believed to be untrappable; we have 463 since learned to tap it by bending the fiber and collecting 464 incidental light, and we have learned about backhoes. As a result, 465 some installations encase fiber optic cable in a pressurized sheath, 466 both to quickly identify the location of a cut and to make it more 467 difficult to tap. 469 While there are protocol behaviors that can detect certain classes of 470 physical faults, such as keep-alive exchanges, physical security is 471 generally not considered to be a protocol problem. 473 For wireless transmission technologies, eavesdropping on the 474 transmitted frames is also typically a concern. Additionally, those 475 operating networks may want to ensure to restrict access to their 476 infrastructure to those who are authenticated and authorized 477 (typically called 'network access authentication'). This procedure 478 is often offered by security primitives at the data link layer. 480 2.2.2. Network, Transport, and Application Layer Security 482 At the network, transport, and application layers, it is common to 483 demand a few basic security requirements, commonly referred to as CIA 484 (Confidentiality, Integrity, and Availability): 486 1. Confidentiality: Protect the transmitted data from unauthorized 487 disclosure (i.e., keep eavesdroppers from learning what was 488 transmitted). For example, for trust in e-commerce applications 489 credit card transactions are exchanged encrypted between the Web 490 browser and a Web server. 492 2. Integrity: Protect against unauthorized changes to exchanges, 493 including both intentional change or destruction and accidental 494 change or loss, by ensuring that changes to exchanges are 495 detectable. It has two parts: one for the data and one for the 496 peers. 498 * Peers need to verify that information that appears to be from 499 a trusted peer is really from that peer. This is typically 500 called 'data origin authentication'. 502 * Peers need to validate that the content of the data exchanged 503 is unmodified. The term typically used for this property is 504 data integrity. 506 3. Availability: Ensure that the resource is accessible by 507 mitigating of denial of service attacks. 509 To this we add authenticity, which requires that the communicating 510 peers prove that they are in fact who they say they are to each other 511 (i.e., mutual authentication). This generally means knowing "who" 512 the peer is, and that they demonstrate the possession of a "secret" 513 as part of the security protocol interaction. 515 The following three examples aim to illustrate these security 516 requirements. 518 One common attack against a TCP session is to bombard the session 519 with reset messages. Other attacks against TCP include the "SYN 520 flooding" attack, in which an attacker attempts to exhaust the memory 521 of the target by creating TCP state. In particular, the attacker 522 attempts to exhaust the target's memory by opening a large number of 523 unique TCP connections, each of which is represented by a 524 Transmission Control Block (TCB). The attack is successful if the 525 attacker can cause the target to fill its memory with TCBs. 527 A number of mechanisms have been developed to deal with these types 528 of denial of service attacks. One, SYN Cookies, delays state 529 establishment on the server side to a later phase in the protocol 530 exchange. Another mechanism, specifically targeting the reset attack 531 cited above, provides authentication services in TCP itself to ensure 532 that fake resets are rejected. 534 Another approach would be to offer security protection already at a 535 lower layer, such as IPsec (see Section 3.1.2) or TLS (see 536 Section 3.1.3), so that a host can identify legitimate messages and 537 discard the others, thus mitigating any damage that may have been 538 caused by the attack. 540 Another common attack involves unauthorized access to resources. For 541 example, an unauthorized party might try to attach to a network. To 542 protect against such an attack, an Internet Service Provider (ISP) 543 typically requires network access authentication of new hosts 544 demanding access to the network and to the Internet prior to offering 545 access. This exchange typically requires authentication of that 546 entity and a check in the ISPs back-end database to determine whether 547 corresponding subscriber records exist and still valid (e.g. active 548 subscription and sufficient credits). 550 From the discussion above, establishing a secure communication 551 channel is clearly an important concept frequently used to mitigate a 552 range of attacks. Unfortunately, focusing only on channel security 553 may not be enough for a given task. Threat models have evolved and 554 even some of the communication endpoints cannot be considered fully 555 trustworthy, i.e. even trusted peers may act maliciously. 557 Furthermore, many protocols are more sophisticated in their protocol 558 interaction and involve more than two parties in the protocol 559 exchange. Many of the application layer protocols, such as email, 560 instant messaging, voice over IP, and presence based applications, 561 fall into this category. With this class of protocols in addition to 562 secure channels between two parties also security between non- 563 neighboring communication partners need to be considered. A detailed 564 treatment of the security threats and requirements of these multi- 565 party protocols is beyond this specification but the interested 566 reader is referred to the above-mentioned examples for an 567 illustration of what technical mechanisms have been investigated and 568 proposed in the past. 570 2.3. Network Infrastructure 572 While the following protocols are not critical to the design of a 573 specific system, they are important to running a network, and as such 574 are surveyed here. 576 2.3.1. Domain Name System (DNS) 578 The DNS' main function is translating names to numeric IP addresses. 579 While this is not critical to running a network, certain functions 580 are made a lot easier if numeric addresses can be replaced with 581 mnemonic names. This facilitates renumbering of networks and 582 generally improves the manageability and serviceability of the 583 network. DNS has a set of security extensions called DNSSEC, which 584 can be used to provide strong cryptographic authentication to the 585 DNS. DNS and DNSSEC are discussed further in Section 3.4.1. 587 2.3.2. Network Management 589 Network management has proven to be a difficult problem. As such, 590 various solutions have been proposed, implemented, and deployed. 591 Each solution has its proponents, all of whom have solid arguments 592 for their viewpoints. The IETF has two major network management 593 solutions for device operation: SNMP, which is ASN.1-encoded and is 594 primarily used for monitoring of system variables, and NetConf 595 [RFC4741], which is XML-encoded and primarily used for device 596 configuration. 598 Another aspect of network management is the initial provisioning and 599 configuration of hosts, which is discussed in Section 3.4.2. Note 600 that Smart Grid deployments may require identity authentication and 601 authorization (as well as other provisioning and configuration) that 602 may not be within the scope of either DHCP or Neighbor Discovery. 603 While the IP Protocol Suite has limited support for secure 604 provisioning and configuration, these problems have been solved using 605 IP protocols in specifications such as DOCSIS 3.0 [SP-MULPIv3.0]. 607 3. Specific protocols 609 In this section, having briefly laid out the IP architecture and some 610 of the problems that the architecture tries to address, we introduce 611 specific protocols that might be appropriate to various Smart Grid 612 use cases. Use cases should be analyzed along with privacy, 613 Authentication, Authorization, and Accounting (AAA), transport and 614 network solution dimensions. The following sections provide guidance 615 for such analysis. 617 3.1. Security Toolbox 619 As noted, a key consideration in security solutions is a good threat 620 analysis coupled with appropriate mitigation strategies at each 621 layer. The IETF has over time developed a number of building blocks 622 for security based on the observation that protocols often demand 623 similar security services. The following sub-sections outline a few 624 of those commonly used security building blocks. Re-using them 625 offers several advantages, such as availability of open source code, 626 experience with existing systems, a number of extensions that have 627 been developed, and the confidence that the listed technologies have 628 been reviewed and analyzed by a number of security experts. 630 It is important to highlight that in addition to the mentioned 631 security tools every protocol often comes with additional, often 632 unique security considerations that are unique to the specific domain 633 that protocol operates in. Many protocols include features 634 specifically designed to mitigate these protocol-specific risks. In 635 other cases, the security considerations will identify security- 636 relevant services that are required from other network layers to 637 achieve appropriate levels of security. 639 3.1.1. Authentication, Authorization, and Accounting (AAA) 641 While the term AAA sounds generic and applicable to all sorts of 642 security protocols it has been, in the IETF, used in relation to 643 network access authentication and is associated with the RADIUS 644 ([RFC2865]) and the Diameter protocol ([RFC3588], 645 [I-D.ietf-dime-rfc3588bis]) in particular. 647 The authentication procedure for network access aims to deal with the 648 task of verifying that a peer is authenticated and authorized prior 649 to accessing a particular resource (often connectivity to the 650 Internet). Typically, the authentication architecture for network 651 access consists of the following building blocks: the Extensible 652 Authentication Protocol (EAP [RFC4017]) as a container to encapsulate 653 EAP methods, an EAP Method (as a specific way to perform 654 cryptographic authentication and key exchange, such as RFC 5216 655 [RFC5216], RFC 5433 [RFC5433]), a protocol that carries EAP payloads 656 between the end host and a server side entity (such as a network 657 access server), and a way to carry EAP payloads to back-end server 658 infrastructure (potentially in a cross-domain scenario) to provide 659 authorization and accounting functionality. The latter part is 660 provided by RADIUS and Diameter. To carry EAP payloads between the 661 end host and a network access server different mechanisms have been 662 standardized, such as PANA [RFC5191] and IEEE 802.1X [IEEE802.1X] . 663 For access to remote networks, such as enterprise networks, the 664 ability to utilize EAP within IKEv2 [RFC5996] has also been 665 developed. 667 More recently, the same architecture with EAP and RADIUS/Diameter is 668 being re-used for application layer protocols. More details about 669 this architectural variant can be found in [I-D.lear-abfab-arch]. 671 3.1.2. Network Layer Security 673 IP security, as described in [RFC4301], addresses security at the IP 674 layer, provided through the use of a combination of cryptographic and 675 protocol security mechanisms. It offers a set of security services 676 for traffic at the IP layer, in both the IPv4 and IPv6 environment. 677 The set of security services offered includes access control, 678 connectionless integrity, data origin authentication, detection and 679 rejection of replays (a form of partial sequence integrity), 680 confidentiality (via encryption), and limited traffic flow 681 confidentiality. These services are provided at the IP layer, 682 offering protection in a standard fashion for all protocols that may 683 be carried over IP (including IP itself). 685 The architecture foresees a split between the rather time-consuming 686 (a) authentication and key exchange protocol step that also 687 establishes a security association; a data structure with keying 688 material and security parameters and (b) the actual data traffic 689 protection. 691 For the former step the Internet Key Exchange protocol version 2 692 (IKEv2 [RFC5996]) is the most recent edition of the standardized 693 protocol. IKE negotiates each of the cryptographic algorithms that 694 will be used to protect the data independently, somewhat like 695 selecting items a la carte. 697 For the actual data protection two types of protocols have 698 historically been used, namely the IP Authentication Header (AH) 699 [RFC4302] and the Encapsulating Security Payload (ESP) [RFC4303]. 701 The two differ in the security services they offer; the most 702 important distinction is that ESP offers confidentiality protection 703 while AH does not. Since ESP can also provide authentication 704 services, most recent protocol development making use of IPsec only 705 specify use of ESP and do not use AH. 707 In addition to these base line protocol mechanisms a number of 708 extensions have been developed for IKEv2 (e.g., an extension to 709 perform EAP-only authentication [RFC5998]) and since the architecture 710 supports flexible treatment of cryptographic algorithms a number of 711 them have been specified (e.g., [RFC4307] for IKEv2, and [RFC4835] 712 for AH and ESP). 714 3.1.3. Transport Layer Security 716 Transport Layer Security v1.2 [RFC5246] are security services that 717 protect data above the transport layer. The protocol allows client/ 718 server applications to communicate in a way that is designed to 719 prevent eavesdropping, tampering, or message forgery. TLS is 720 application protocol independent. 722 TLS is composed of two layers: the TLS Record protocol and the TLS 723 Handshake protocol. The TLS Record protocol provides connection 724 security that has two basic properties: (a) confidentiality 725 protection and (b) integrity protection. 727 The TLS Handshake protocol allows the server and client to 728 authenticate each other and to negotiate an encryption algorithm and 729 cryptographic keys before the application protocol transmits or 730 receives its first byte of data. The negotiated parameters and the 731 derived keying material is then used by the TLS Record protocol to 732 perform its job. 734 Unlike IKEv2/IPsec TLS negotiates these cryptographic parameters in 735 suites, so-called cipher suites. Examples of cipher suites that can 736 be negotiated with TLS include Elliptic Curve Cryptography (ECC) 737 [RFC4492][RFC5289][I-D.mcgrew-tls-aes-ccm-ecc], Camellia [RFC5932], 738 and the Suite B Profile [RFC5430]. [IEC62351-3] outlines the use of 739 different TLS Cipher Suites for use in the Smart Grid. The basic 740 cryptographic mechanisms for ECC have been documented in [RFC6090]. 742 TLS must run over a reliable transport channel -- typically TCP. In 743 order to offer the same security services for unreliable datagram 744 traffic, such as UDP, the Datagram Transport Layer Security (DTLS 745 [RFC4347] [I-D.ietf-tls-rfc4347-bis]) was developed. 747 3.1.4. Application Layer Security 749 In certain cases the application layer independent security 750 mechanisms described in the previous sub-sections are not sufficient 751 to deal with all the identified threats. For this purpose, a number 752 of security primitives are additionally available at the application 753 layer where the semantic of the application can be considered. 755 We will focus with our description on a few mechanisms that are 756 commonly used throughout the Internet. 758 Cryptographic Message Syntax (CMS [RFC5652]) is an encapsulation 759 syntax to sign, digest, authenticate, or encrypt arbitrary message 760 content. It also allows arbitrary attributes, such as signing time, 761 to be signed along with the message content, and it provides for 762 other attributes such as countersignatures to be associated with a 763 signature. The CMS can support a variety of architectures for 764 certificate-based key management, such as the one defined by the PKIX 765 (Public Key Infrastructure using X.509) working group [RFC5280]. CMS 766 has been leveraged to supply security services in a variety of 767 protocols, including secure email [RFC5751], key management [RFC5958] 768 and [RFC6031], and firmware updates [RFC4108]. 770 Related work includes the use of digital signatures on XML-encoded 771 documents, which has been jointly standardized by W3C and the IETF 772 [RFC3275]. Digitally signed XML is a good choice where applications 773 natively support XML encoded data, such as XMPP. 775 More recently, the work on delegated authentication and authorization 776 often demanded by Web applications have been developed with the Open 777 Web Authentication (OAuth) protocol [RFC5849], [I-D.ietf-oauth-v2]. 778 OAuth is used by third-party applications to gain access to protected 779 resources (such as energy consumption information about a specific 780 household), without having the resource owner to shares its long-term 781 credentials with that third-party. In OAuth, the third-party 782 application requests access to resources controlled by the resource 783 owner and hosted by the resource server, and is issued a different 784 set of credentials than those of the resource owner. More 785 specifically, the third-party applications obtains an access token, a 786 string denoting a specific scope, duration, and other access 787 attributes, during the OAuth protocol exchange securely gain access 788 to the protected resource with the consent of the resource owner. 790 3.1.5. Secure Shell 792 The Secure Shell (SSH) protocol [RFC4253] has been widely used by 793 administrators and others for secure remote login, but is also usable 794 for secure tunelling. More recently, protocols have chosen to layer 795 on top of SSH in for transport security services, for example the 796 netconf network management protocol (see Section 3.5.2) uses SSH as 797 its main communications security protocol. 799 3.1.6. Key Management Infrastructures 801 All the above security protocols depend on cryptography for security, 802 and hence require some form of key management. Most IETF protocols 803 at least nominally require some scalable form of key management to be 804 defined as mandatory to implement, indeed the lack of such key 805 management features has in the past been a reason to delay approval 806 of protocols. There are two generic key management schemes that are 807 widely used by other Internet protocols, PKIX and Kerberos, each of 808 which is briefly described below. 810 3.1.6.1. PKIX 812 Public Key Infrastructure (PKI) refers to the kind of key management 813 that is based on certification authorities (CAs) issuing public key 814 certificates for other key holders. By chaining from a trust anchor 815 (a locally trusted copy of a CA public key), down to the public key 816 of some protocol peer, PKI allows for secure binding between keys and 817 protocol-specific names, such as email addresses, and hence enables 818 security services such as data and peer authentication, data 819 integrity and confidentiality (encryption). 821 The main Internet standard for PKI is [RFC5280] which is a profile of 822 the X.509 public key certificate format. There are a range of 823 private and commercial CAs operating today providing the ability to 824 manage and securely distribute keys for all protocols that use public 825 key certificates, e.g. TLS, S/MIME. In addition to the profile 826 standard, the PKIX working group has defined a number of management 827 protocols (e.g. [RFC5272], [RFC4210]) as well as protocols for 828 handling revocation of public key certificates such as the Online 829 Certificate Status Protocol (OCSP). [RFC2560] 831 PKI is generally perceived to better handle use-cases spanning 832 multiple independent domains when compared to Kerberos. 834 3.1.6.2. Kerberos 836 The Kerberos network Authentication System [RFC4120] is commonly used 837 within organizations to centralize authentication, authorization and 838 policy in one place. Kerberos natively supports usernames and 839 passwords as the basis of authentication. With Pkinit [RFC4556], 840 Kerberos supports certificate or public-key-based authentication. 841 This may provide an advantage by concentrating policy about 842 certificate validation and mapping of certificates to user accounts 843 in one place. Through the GSS-API [RFC1964] [RFC2743] [RFC4121], 844 Kerberos can be used to manage authentication for most applications. 845 While Kerberos works best within organizations and enterprises, it 846 does have facilities that permit authentication to be shared between 847 administrative domains. 849 3.2. Network Layer 851 The IPS specifies two network layer protocols: IPv4 and IPv6. The 852 following sections describe the IETF's coexistence and transition 853 mechanisms for IPv4 and IPv6. 855 Note that on 3 February 2011 the IANA's IPv4 free pool (the pool of 856 available, unallocated IPv4 addresses) was exhausted, and the RIR 857 free pools are expected to be exhausted during them coming year at 858 most. The IETF, the IANA, and the Regional Internet Registrars 859 recommends that new deployments use IPv6, and that IPv4 860 infrastructures are supported via the mechanisms described in 861 Section 3.2.1. 863 3.2.1. IPv4/IPv6 Coexistence Advice 865 The IETF has specified a variety of mechanisms designed to facilitate 866 IPv4/IPv6 coexistence. The IETF actually recommends relatively few 867 of them: the current advice to network operators is found in 868 Guidelines for Using IPv6 Transition Mechanisms 869 [I-D.arkko-ipv6-transition-guidelines]. The thoughts in that 870 document are replicated here. 872 3.2.1.1. Dual Stack Coexistence 874 The simplest coexistence approach is to 876 o provide a network that routes both IPv4 and IPv6, 878 o ensure that servers and their applications similarly support both 879 protocols, and 881 o require that all new systems and applications purchased or 882 upgraded support both protocols. 884 The net result is that over time all systems become protocol 885 agnostic, and that eventually maintenance of IPv4 support becomes a 886 business decision. This approach is described in the Basic 887 Transition Mechanisms for IPv6 Hosts and Routers [RFC4213]. 889 3.2.1.2. Tunneling Mechanism 891 In those places in the network that support only IPv4 the simplest 892 and most reliable approach is to provide virtual connectivity using 893 tunnels or encapsulations. Early in the IPv6 deployment, this was 894 often done using static tunnels. A more dynamic approach is 895 documented in IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) 896 [RFC5569]. 898 3.2.1.3. Translation between IPv4 and IPv6 Networks 900 In those cases where an IPv4-only host would like to communicate with 901 an IPv6-only host (or vice versa), protocol translation may be 902 indicated. At first blush, protocol translation may appear trivial; 903 on deeper inspection, it turns out that protocol translation can be 904 complicated. 906 The most reliable approach to protocol translation is to provide 907 application layer proxies or gateways, which natively enable 908 application-to-application connections using both protocols and can 909 use whichever is appropriate. For example, a web proxy might use 910 both protocols and as a result enable an IPv4-only system to run HTTP 911 across on IPv6-only network or to a web server that implements only 912 IPv6. Since this approach is a service of a protocol-agnostic 913 server, it is not the subject of standardization by the IETF. 915 For those applications in which network layer translation is 916 indicated, the IETF has designed a translation mechanism which is 917 described in the following documents: 919 o Framework for IPv4/IPv6 Translation 920 [I-D.ietf-behave-v6v4-framework] 922 o IPv6 Addressing of IPv4/IPv6 Translators [RFC6052] 924 o DNS extensions [I-D.ietf-behave-dns64] 926 o IP/ICMP Translation Algorithm [I-D.ietf-behave-v6v4-xlate] 928 o Translation from IPv6 Clients to IPv4 Servers 929 [I-D.ietf-behave-v6v4-xlate-stateful] 931 As with IPv4/IPv4 Network Address Translation, translation between 932 IPv4 and IPv6 has limited real world applicability for an application 933 protocol which carry IP addresses in its payload and expects those 934 addresses to be meaningful to both client and server. However, for 935 those protocols that do not, protocol translation can provide a 936 useful network extension. 938 Network-based translation provides for two types of services: 939 stateless (and therefore scalable and load-sharable) translation 940 between IPv4 and IPv6 addresses that embed an IPv4 address in them, 941 and stateful translation similar to IPv4/IPv4 translation between 942 IPv4 addresses. The stateless mode is straightforward to implement, 943 but due to the embedding, requires IPv4 addresses to be allocated to 944 an otherwise IPv6-only network, and is primarily useful for IPv4- 945 accessible servers implemented in the IPv6 network. The stateful 946 mode allows clients in the IPv6 network to access servers in the IPv4 947 network, but does not provide such service for IPv4 clients accessing 948 IPv6 peers or servers with general addresses; it has the advantage 949 that it does not require that a unique IPv4 address be embedded in 950 the IPv6 address of hosts using this mechanism. 952 Finally, note that some site networks are IPv6 only while some 953 transit networks are IPv4 only. In these cases, it may be necessary 954 to tunnel IPv6 over IPv4 or translate between IPv6 and IPv4. 956 3.2.2. Internet Protocol Version 4 958 IPv4 [RFC0791] and the Internet Control Message Protocol [RFC0792] 959 comprise the IPv4 network layer. IPv4 provides unreliable delivery 960 of datagrams. 962 IPv4 also provides for fragmentation and reassembly of long datagrams 963 for transmission through networks with small Maximum Transmission 964 Units (MTU). The MTU is the largest packet size that can be 965 delivered across the network. In addition, the IPS provides the 966 Internet Control Message Protocol (ICMP) [RFC0792], which is a 967 separate protocol that enables the network to report errors and other 968 issues to hosts that originate problematic datagrams. 970 IPv4 originally supported an experimental type of service field that 971 identified eight levels of operational precedence styled after the 972 requirements of military telephony, plus three and later four bit 973 flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2 974 [RFC2328] interpreted as control traffic; this control traffic is 975 assured of not being dropped when queued or upon receipt, even if 976 other traffic is being dropped.. These control bits turned out to be 977 less useful than the designers had hoped. They were replaced by the 978 Differentiated Services Architecture [RFC2474][RFC2475], which 979 contains a six bit code point used to select an algorithm (a "per-hop 980 behavior") to be applied to the datagram. The IETF has also produced 981 a set of Configuration Guidelines for DiffServ Service Classes 982 [RFC4594], which describes a set of service classes that may be 983 useful to a network operator. 985 3.2.2.1. IPv4 Address Allocation and Assignment 987 IPv4 addresses are administratively assigned, usually using automated 988 methods, and assigned using the Dynamic Host Configuration Protocol 989 (DHCP) [RFC2131]. On most interface types, neighboring systems 990 identify each other's addresses using the Address Resolution Protocol 991 (ARP) [RFC0826]. 993 3.2.2.2. IPv4 Unicast Routing 995 Routing for the IPv4 Internet is accomplished by routing applications 996 that exchange connectivity information and build semi-static 997 destination routing databases. If a datagram is directed to a given 998 destination address, the address is looked up in the routing 999 database, and the most specific ("longest") prefix found that 1000 contains it is used to identify the next hop router, or the end 1001 system it will be delivered to. This is not generally implemented on 1002 hosts, although it can be; a host normally sends datagrams to a 1003 router on its local network, and the router carries out the intent. 1005 IETF specified routing protocols include RIP Version 2 [RFC2453], OSI 1006 IS-IS for IPv4 [RFC1195], OSPF Version 2 [RFC2328], and BGP-4 1007 [RFC4271]. Active research exists in mobile ad hoc routing and other 1008 routing paradigms; these result in new protocols and modified 1009 forwarding paradigms. 1011 3.2.2.3. IPv4 Multicast Forwarding and Routing 1013 IPv4 was originally specified as a unicast (point to point) protocol, 1014 and was extended to support multicast in [RFC1112]. This uses the 1015 Internet Group Management Protocol [RFC3376][RFC4604] to enable 1016 applications to join multicast groups, and for most applications uses 1017 Source-Specific Multicast [RFC4607] for routing and delivery of 1018 multicast messages. 1020 An experiment carried out in IPv4 that is not part of the core 1021 Internet architecture but may be of interest in the Smart Grid is the 1022 development of so-called "Reliable Multicast". This is "so-called" 1023 because it is not "reliable" in the strict sense of the word - it is 1024 perhaps better described as "enhanced reliability". A best effort 1025 network by definition can lose traffic, duplicate it, or reorder it, 1026 something as true for multicast as for unicast. Research in 1027 "Reliable Multicast" technology intends to improve the probability of 1028 delivery of multicast traffic. 1030 In that research, the IETF imposed guidelines [RFC2357] on the 1031 research community regarding what was desirable. Important results 1032 from that research include a number of papers and several proprietary 1033 protocols including some that have been used in support of business 1034 operations. RFCs in the area include The Use of Forward Error 1035 Correction (FEC) in Reliable Multicast [RFC3453], the Negative- 1036 acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol 1037 [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP) 1038 [RFC4410]. 1040 3.2.3. Internet Protocol Version 6 1042 IPv6 [RFC2460], with the Internet Control Message Protocol "v6" 1043 [RFC4443], constitutes the next generation protocol for the Internet. 1044 IPv6 provides for transmission of datagrams from source to 1045 destination hosts, which are identified by fixed length addresses. 1047 IPv6 also provides for fragmentation and reassembly of long datagrams 1048 by the originating host, if necessary, for transmission through 1049 "small packet" networks. ICMPv6, which is a separate protocol 1050 implemented along with IPv6, enables the network to report errors and 1051 other issues to hosts that originate problematic datagrams. 1053 IPv6 adopted the Differentiated Services Architecture 1054 [RFC2474][RFC2475], which contains a six bit code point used to 1055 select an algorithm (a "per-hop behavior") to be applied to the 1056 datagram. 1058 The IPv6 over Low-Power Wireless Personal Area Networks [RFC4919] RFC 1059 and the Compression Format for IPv6 Datagrams in 6LoWPAN Networks 1060 [I-D.ietf-6lowpan-hc] addresses IPv6 header compression and subnet 1061 architecture in at least some sensor networks, and may be appropriate 1062 to the Smart Grid Advanced Metering Infrastructure or other sensor 1063 domains. 1065 3.2.3.1. IPv6 Address Allocation and Assignment 1067 An IPv6 Address [RFC4291] may be administratively assigned using 1068 DHCPv6 [RFC3315] in a manner similar to the way IPv4 addresses are. 1069 In addition, IPv6 addresses may also be autoconfigured. 1070 Autoconfiguration enables various models of network management which 1071 may be advantageous in different use cases. Autoconfiguration 1072 procedures are defined in [RFC4862] and [RFC4941]. IPv6 neighbors 1073 identify each other's addresses using either Neighbor Discovery (ND) 1074 [RFC4861]. SEcure Neighbor Discovery (SEND) [RFC3971] may be used to 1075 secure these operations. 1077 3.2.3.2. IPv6 Routing 1079 Routing for the IPv6 Internet is accomplished by routing applications 1080 that exchange connectivity information and build semi-static 1081 destination routing databases. If a datagram is directed to a given 1082 destination address, the address is looked up in the routing 1083 database, and the most specific ("longest") prefix found that 1084 contains it is used to identify the next hop router, or the end 1085 system it will be delivered to. Routing is not generally implemented 1086 on hosts (although it can be); generally, a host sends datagrams to a 1087 router on its local network, and the router carries out the intent. 1089 IETF specified routing protocols include RIP for IPv6 [RFC2080], 1090 IS-IS for IPv6 [RFC5308], OSPF for IPv6 [RFC5340], and BGP-4 for IPv6 1091 [RFC2545]. Active research exists in mobile ad hoc routing, routing 1092 in low power networks (sensors and Smart Grids) and other routing 1093 paradigms; these result in new protocols and modified forwarding 1094 paradigms. 1096 3.2.4. Routing for IPv4 and IPv6 1098 3.2.4.1. Routing Information Protocol 1100 The prototypical routing protocol used in the Internet has probably 1101 been the Routing Information Protocol [RFC1058]. People that use it 1102 today tend to deploy RIPng for IPv6 [RFC2080] and RIP Version 2 1103 [RFC2453]. Briefly, RIP is a distance vector routing protocol that 1104 is based on a distributed variant of the widely known Bellman-Ford 1105 algorithm. In distance vector routing protocols, each router 1106 announces the contents of its route table to neighboring routers, 1107 which integrate the results with their route tables and re-announce 1108 them to others. It has been characterized as "routing by rumor", and 1109 suffers many of the ills we find in human gossip - propagating stale 1110 or incorrect information in certain failure scenarios, and being in 1111 cases unresponsive to changes in topology. [RFC1058] provides 1112 guidance to algorithm designers to mitigate these issues. 1114 3.2.4.2. Open Shortest Path First 1116 The Open Shortest Path First (OSPF) routing protocol is one of the 1117 more widely used protocols in the Internet. OSPF is a based on 1118 Dijkstra's well known shortest path first (SPF) algorithm. It is 1119 implemented as OSPF Version 2 [RFC2328] for IPv4, OSPF for IPv6 1120 [RFC5340] for IPv6, and the Support of Address Families in OSPFv3 1121 [RFC5838] to enable [RFC5340] to route both IPv4 and IPv6. 1123 The advantage of any SPF-based protocol (i.e., OSPF and IS-IS) is 1124 primarily that every router in the network constructs its view of the 1125 network from first hand knowledge rather than the "gossip" that 1126 distance vector protocols propagate. As such, the topology is 1127 quickly and easily changed by simply announcing the change. The 1128 disadvantage of SPF-based protocols is that each router must store a 1129 first-person statement of the connectivity of each router in the 1130 domain. 1132 3.2.4.3. ISO Intermediate System to Intermediate System 1134 The Intermediate System to Intermediate System (IS-IS) routing 1135 protocol is one of the more widely used protocols in the Internet. 1136 IS-IS is also based on Dijkstra's SPF algorithm. It was originally 1137 specified as ISO DP 10589 for the routing of CLNS, and extended for 1138 routing in TCP/IP and dual environments [RFC1195], and more recently 1139 for routing of IPv6 [RFC5308]. 1141 As with OSPF, the positives of any SPF-based protocol and 1142 specifically IS-IS are primarily that the network is described as a 1143 lattice of routers with connectivity to subnets and isolated hosts. 1144 It's topology is quickly and easily changed by simply announcing the 1145 change, without the issues of "routing by rumor", since every host 1146 within the routing domain has a first-person statement of the 1147 connectivity of each router in the domain. The negatives are a 1148 corollary: each router must store a first-person statement of the 1149 connectivity of each router in the domain. 1151 3.2.4.4. Border Gateway Protocol 1153 The Border Gateway Protocol (BGP) [RFC4271] is widely used in the 1154 IPv4 Internet to exchange routes between administrative entities - 1155 service providers, their peers, their upstream networks, and their 1156 customers - while applying specific policy. Multi-protocol 1157 Extensions [RFC4760] to BGP allow BGP to carry IPv6 Inter-Domain 1158 Routing [RFC2545], multicast reachability information, and VPN 1159 information, among others. 1161 Considerations that apply with BGP deal with the flexibility and 1162 complexity of the policies that must be defined. Flexibility is a 1163 good thing; in a network that is not run by professionals, the 1164 complexity is burdensome. 1166 3.2.4.5. Dynamic MANET On-demand (DYMO) Routing 1168 The Mobile Ad Hoc Working Group of the IETF developed, among other 1169 protocols, the Ad hoc On-Demand Distance Vector (AODV) Routing 1170 [RFC3561]. This protocol captured the minds of some in the embedded 1171 devices industry, but experienced issues in wireless networks such as 1172 802.15.4 and 802.11's Ad Hoc mode. As a result, it is in the process 1173 of being updated in the Dynamic MANET On-demand (DYMO) Routing 1174 [I-D.ietf-manet-dymo] protocol. 1176 AODV and DYMO are essentially reactive routing protocols designed for 1177 mobile ad hoc networks, and usable in other forms of ad hoc networks. 1178 They provide connectivity between a device within a distributed 1179 subnet and a few devices (including perhaps a gateway or router to 1180 another subnet) without tracking connectivity to other devices. In 1181 essence, routing is calculated and discovered upon need, and a host 1182 or router need only maintain the routes that currently work and are 1183 needed. 1185 3.2.4.6. Optimized Link State Routing Protocol 1187 The Optimized Link State Routing Protocol (OLSR) [RFC3626] is a 1188 proactive routing protocol designed for mobile ad hoc networks, and 1189 can be used in other forms of ad hoc networks. It provides arbitrary 1190 connectivity between systems within a distributed subnet. As with 1191 protocols designed for wired networks, routing is calculated and 1192 maintained whenever changes are detected, and maintained in each 1193 router's tables. The set of nodes that operate as routers within the 1194 subnet, however, are fairly fluid, and dependent on this 1195 instantaneous topology of the subnet. 1197 3.2.4.7. Routing for Low power and Lossy Networks 1199 The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) 1200 [I-D.ietf-roll-rpl] is a reactive routing protocol designed for use 1201 in resource constrained networks. Requirements for resource 1202 constrained networks are defined in [RFC5548], [RFC5673], [RFC5826], 1203 and [RFC5867]. 1205 Briefly, a constrained network is comprised of nodes that: 1207 o Are built with limited processing power and memory, and sometimes 1208 energy when operating on batteries. 1210 o Are interconnected through a low-data-rate network interface and 1211 potentially vulnerable to communication instability and low packet 1212 delivery rates. 1214 o Potentially have a mix of roles such as being able to act as a 1215 host (i.e., generating traffic) and/or a router (i.e., both 1216 forwarding and generating RPL traffic). 1218 3.2.5. IPv6 Multicast Forwarding and Routing 1220 IPv6 specifies both unicast and multicast datagram exchange. This 1221 uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710] 1222 [RFC3590] [RFC3810] [RFC4604] to enable applications to join 1223 multicast groups, and for most applications uses Source-Specific 1224 Multicast [RFC4607] for routing and delivery of multicast messages. 1226 The mechanisms experimentally developed for reliable multicast in 1227 IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well. 1229 3.2.5.1. Protocol-Independent Multicast Routing 1231 A multicast routing protocol has two basic functions: Building the 1232 multicast distribution tree and forwarding multicast traffic. 1233 Multicast routing protocols generally contain a control plane for 1234 building distribution trees, and a forwarding plane that uses the 1235 distribution tree when forwarding multicast traffic. 1237 The multicast model works as follows: hosts express their interest in 1238 receiving multicast traffic from a source by sending a Join message 1239 to their first hop router. That router in turn sends a Join message 1240 upstream towards the root of the tree, grafting the router (leaf 1241 node) onto the distribution tree for the group. Data is delivered 1242 down the tree toward the leaf nodes, which forward it onto the local 1243 network for delivery. 1245 The initial multicast model deployed in the Internet was known as 1246 Any-Source Multicast (ASM). In the ASM model any host could send to 1247 the group, and inter-domain multicast was difficult. Protocols such 1248 as Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol 1249 Specification (Revised) [RFC3973] and Protocol Independent Multicast 1250 - Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601] 1251 were designed for the ASM model. 1253 Many modern multicast deployments use Source-Specific Multicast (PIM- 1254 SSM) [RFC3569][RFC4608]. In the SSM model, a host expresses interest 1255 in a "channel", which is comprised of a source (S) and a group (G). 1256 Distribution trees are rooted to the sending host (called an "(S,G) 1257 tree"). Since only the source S can send on to the group, SSM has 1258 inherent anti-jamming capability. In addition, inter-domain 1259 multicast is simplified since it is the responsibility of the 1260 receivers (rather than the network) to find the (S,G) channel they 1261 are interested in receiving. This implies that SSM requires some 1262 form of directory service so that receivers can find the (S,G) 1263 channels. 1265 3.2.6. Adaptation to lower layer networks and link layer protocols 1267 In general, the layered architecture of the Internet enables the IPS 1268 to run over any appropriate layer two architecture. The ability to 1269 change the link or physical layer without having to rethink the 1270 network layer, transports, or applications has been a great benefit 1271 in the Internet. 1273 Examples of link layer adaptation technology include: 1275 Ethernet/IEEE 802.3: IPv4 has run on each link layer environment 1276 that uses the Ethernet header (which is to say 10 and 100 MBPS 1277 wired Ethernet, 1 and 10 GBPS wired Ethernet, and the various 1278 versions of IEEE 802.11) using [RFC0894]. IPv6 does the same 1279 using [RFC2464]. 1281 PPP: The IETF has defined a serial line protocol, the Point-to-Point 1282 Protocol (PPP) [RFC1661], that uses HDLC (bit-synchronous or byte 1283 synchronous) framing. The IPv4 adaptation specification is 1284 [RFC1332], and the IPv6 adaptation specification is [RFC5072]. 1285 Current use of this protocol is in traditional serial lines, 1286 authentication exchanges in DSL networks using PPP Over Ethernet 1287 (PPPoE) [RFC2516], and in the Digital Signaling Hierarchy 1288 (generally referred to as Packet-on-SONET/SDH) using PPP over 1289 SONET/SDH [RFC2615]. 1291 IEEE 802.15.4: The adaptation specification for IPv6 transmission 1292 over IEEE 802.15.4 Networks is [RFC4944]. 1294 Numerous other adaptation specifications exist, including ATM, Frame 1295 Relay, X.25, other standardized and proprietary LAN technologies, and 1296 others. 1298 3.3. Transport Layer 1300 This section outlines the functionality of UDP, TCP, SCTP, and DCCP. 1301 UDP and TCP are best known and most widely used in the Internet 1302 today, while SCTP and DCCP are newer protocols that built for 1303 specific purposes. Other transport protocols can be built when 1304 required. 1306 3.3.1. User Datagram Protocol (UDP) 1308 The User Datagram Protocol [RFC0768] and the Lightweight User 1309 Datagram Protocol [RFC3828] are properly not "transport" protocols in 1310 the sense of "a set of rules governing the exchange or transmission 1311 of data electronically between devices". They are labels that 1312 provide for multiplexing of applications directly on the IP layer, 1313 with transport functionality embedded in the application. 1315 Many exchange designs have been built using UDP, and many of them 1316 have not worked out. As a result, the use of UDP really should be 1317 treated as designing a new transport. Advice on the use of UDP in 1318 new applications can be found in Unicast UDP Usage Guidelines for 1319 Application Designers [RFC5405]. 1321 Datagram Transport Layer Security [RFC5238] can be used to prevent 1322 eavesdropping, tampering, or message forgery for applications that 1323 run over UDP. Alternatively, UDP can run over IPsec. 1325 3.3.2. Transmission Control Protocol (TCP) 1327 TCP [RFC0793] is the predominant transport protocol in use in the 1328 Internet. It is "reliable", as the term is used in protocol design: 1329 it delivers data to its peer and provides acknowledgement to the 1330 sender, or it dies trying. It has extensions for Congestion Control 1331 [RFC5681] and Explicit Congestion Notification [RFC3168]. 1333 The user interface for TCP is a byte stream interface - an 1334 application using TCP might "write" to it several times only to have 1335 the data compacted into a common segment and delivered as such to its 1336 peer. For message-stream interfaces, ACSE/ROSE uses the ISO 1337 Transport Service on TCP [RFC1006][RFC2126] in the application. 1339 Transport Layer Security [RFC5246] can be used to prevent 1340 eavesdropping, tampering, or message forgery. Alternatively, TCP can 1341 run over IPsec. Additionally, [RFC4987] discusses mechanisms similar 1342 to SCTP and DCCP's "cookie" approach that may be used to secure TCP 1343 sessions against flooding attacks. 1345 Finally, note that TCP has been the subject of ongoing research and 1346 development since it was written. The Roadmap for TCP Specification 1347 Documents [RFC4614] captures this history, and is intended to be a 1348 guide to current and future developers in the area. 1350 3.3.3. Stream Control Transmission Protocol (SCTP) 1352 SCTP [RFC4960] is a more recent reliable transport protocol that can 1353 be imagined as a TCP-like context containing multiple separate and 1354 independent message streams (unlike TCP's byte streams). The design 1355 of SCTP includes appropriate congestion avoidance behavior and 1356 resistance to flooding and masquerade attacks. As it uses a message 1357 stream interface, it may also be more appropriate for the ISO 1358 Transport Service than using RFC 1006/2126 to turn TCP's octet 1359 streams into a message interface. 1361 SCTP offers several delivery options. The basic service is 1362 sequential non-duplicated delivery of messages within a stream, for 1363 each stream in use. Since streams are independent, one stream may 1364 pause due to head of line blocking while another stream in the same 1365 session continues to deliver data. In addition, SCTP provides a 1366 mechanism for bypassing the sequenced delivery service. User 1367 messages sent using this mechanism are delivered to the SCTP user as 1368 soon as they are received. 1370 SCTP implements a simple "cookie" mechanism intended to limit the 1371 effectiveness of flooding attacks by mutual authentication. This 1372 demonstrates that the application is connected to the same peer, but 1373 does not identify the peer. Mechanisms also exist for Dynamic 1374 Address Reconfiguration [RFC5061], enabling peers to change addresses 1375 during the session and yet retain connectivity. Transport Layer 1376 Security [RFC3436] can be used to prevent eavesdropping, tampering, 1377 or message forgery. Alternatively, SCTP can run over IPsec. 1379 3.3.4. Datagram Congestion Control Protocol (DCCP) 1381 DCCP [RFC4340] is an "unreliable" transport protocol (e.g., one that 1382 does not guarantee message delivery) that provides bidirectional 1383 unicast connections of congestion-controlled unreliable datagrams. 1384 DCCP is suitable for applications that transfer fairly large amounts 1385 of data and that can benefit from control over the tradeoff between 1386 timeliness and reliability. 1388 DCCP implements a simple "cookie" mechanism intended to limit the 1389 effectiveness of flooding attacks by mutual authentication. This 1390 demonstrates that the application is connected to the same peer, but 1391 does not identify the peer. Datagram Transport Layer Security 1392 [RFC5238] can be used to prevent eavesdropping, tampering, or message 1393 forgery. Alternatively, DCCP can run over IPsec. 1395 3.4. Infrastructure 1397 3.4.1. Domain Name System 1399 In order to facilitate network management and operations, the 1400 Internet Community has defined the Domain Name System (DNS) 1401 [RFC1034][RFC1035]. Names are hierarchical: a name like example.com 1402 is found registered with a .com registrar, and within the associated 1403 network other names like baldur.cincinatti.example.com can be 1404 defined, with obvious hierarchy. Security extensions, which allow a 1405 registry to sign the records it contains and in so doing demonstrate 1406 their authenticity, are defined by the DNS Security Extensions 1407 [RFC4033][RFC4034][RFC4035]. 1409 Devices can also optionally update their own DNS record. For 1410 example, a sensor that is using Stateless Address Autoconfiguration 1411 [RFC4862] to create an address might want to associate it with a name 1412 using DNS Dynamic Update [RFC2136] or DNS Secure Dynamic Update 1413 [RFC3007]. 1415 3.4.2. Dynamic Host Configuration 1417 As discussed in Section 3.2.2, IPv4 address assignment is generally 1418 performed using DHCP [RFC2131]. By contrast, Section 3.2.3 points 1419 out that IPv6 address assignment can be accomplished using either 1420 autoconfiguration [RFC4862][RFC4941] or DHCPv6 [RFC3315]. The best 1421 argument for the use of autoconfiguration is a large number of 1422 systems that require little more than a random number as an address; 1423 the argument for DHCP is administrative control. 1425 There are other parameters that may need to be allocated to hosts 1426 requiring administrative configuration; examples include the 1427 addresses of DNS servers, keys for Secure DNS and Network Time 1428 servers. 1430 3.4.3. Network Time 1432 The Network Time Protocol was originally designed by Dave Mills of 1433 the University of Delaware and CSNET, implementing a temporal metric 1434 in the Fuzzball Routing Protocol and generally coordinating time 1435 experiments. The current versions of the time protocol are the 1436 Network Time Protocol [RFC5905]. 1438 3.5. Network Management 1440 The IETF has developed two protocols for network management: SNMP and 1441 NETCONF. SNMP is discussed in Section 3.5.1, and NETCONF is 1442 discussed in Section 3.5.2. 1444 3.5.1. Simple Network Management Protocol (SNMP) 1446 The Simple Network Management Protocol, originally specified in the 1447 late 1980's and having passed through several revisions, is specified 1448 in several documents: 1450 o An Architecture for Describing Simple Network Management Protocol 1451 (SNMP) Management Frameworks [RFC3411] 1453 o Message Processing and Dispatching [RFC3412] 1455 o SNMP Applications [RFC3413] 1457 o User-based Security Model (USM) for SNMP version 3 [RFC3414] 1459 o View-based Access Control Model (VACM) [RFC3415] 1461 o Version 2 of the SNMP Protocol Operations [RFC3416] 1463 o Transport Mappings [RFC3417] 1465 o Management Information Base (MIB) [RFC3418] 1466 It provides capabilities for polled and event-driven activities, and 1467 for both monitoring and configuration of systems in the field. 1468 Historically, it has been used primarily for monitoring nodes in a 1469 network. Messages and their constituent data are encoded using a 1470 profile of ASN.1. 1472 3.5.2. Network Configuration (NETCONF) Protocol 1474 The NETCONF Configuration Protocol is specified in one basic 1475 document, with supporting documents for carrying it over the IPS. 1476 These documents include: 1478 o NETCONF Configuration Protocol [RFC4741] 1480 o Using the NETCONF Configuration Protocol over Secure SHell (SSH) 1481 [RFC4742] 1483 o Using NETCONF over the Simple Object Access Protocol (SOAP) 1484 [RFC4743] 1486 o Using the NETCONF Protocol over the Blocks Extensible Exchange 1487 Protocol (BEEP) [RFC4744] 1489 o NETCONF Event Notifications [RFC5277] 1491 o NETCONF over Transport Layer Security (TLS) [RFC5539] 1493 o Partial Lock Remote Procedure Call (RPC) for NETCONF [RFC5717] 1495 NETCONF was developed in response to operator requests for a common 1496 configuration protocol based on ASCII text, unlike ASN.1. In 1497 essence, it carries XML-encoded remote procedure call (RPC) data. In 1498 response to Smart Grid requirements, there is consideration of a 1499 variant of the protocol that could be used for polled and event- 1500 driven management activities, and for both monitoring and 1501 configuration of systems in the field. 1503 3.6. Service and Resource Discovery 1505 Service and resource discovery are among the most important protocols 1506 for constrained resource self-organizing networks. These include 1507 various sensor networks as well as the Home Area Networks (HANs), 1508 Building Area Networks (BANs) and Field Area Networks (FANs) 1509 envisioned by Smart Grid architects. 1511 3.6.1. Service Discovery 1513 Service discovery protocols are designed for the automatic 1514 configuration and detection of devices, and the services offered by 1515 the discovered devices. In many cases service discovery is performed 1516 by so-called "constrained resource" devices (i.e., those with limited 1517 processing power, memory, and power resources). 1519 In general, service discovery is concerned with the resolution and 1520 distribution of host names via multicast DNS 1521 [I-D.cheshire-dnsext-multicastdns] and the automatic location of 1522 network services via DHCP (Section 3.4.2), the DNS Service Discovery 1523 (DNS-SD) [I-D.cheshire-dnsext-dns-sd] (part of Apple's Bonjour 1524 technology) and the Service Location Protocol (SLP) [RFC2608]. 1526 3.6.2. Resource Discovery 1528 Resource Discovery is concerned with the discovery of resources 1529 offered by end-points and is extremely important in machine-to- 1530 machine closed-loop applications (i.e., those with no humans in the 1531 loop). The goals of resource discovery protocols include: 1533 Simplicity of creation and maintenance of resources 1535 Commonly understood semantics 1537 Conformance to existing and emerging standards 1539 International scope and applicability 1541 Extensibility 1543 Interoperability among collections and indexing systems 1545 The Constrained Application Protocol (CoAP) [I-D.ietf-core-coap] is 1546 being developed in IETF with these goals in mind. In particular, 1547 CoAP is designed for use in constrained resource networks and for 1548 machine-to-machine applications such as smart energy and building 1549 automation. It provides a RESTful transfer protocol [RESTFUL], a 1550 built-in resource discovery protocol, and includes web concepts such 1551 as URIs and content-types. CoAP provides both unicast and multicast 1552 resource discovery and includes the ability to filter on attributes 1553 of resource descriptions. Finally, CoAP resource discovery can also 1554 be used to discover HTTP resources. 1556 For simplicity, CoAP makes the assumption that all CoAP servers 1557 listen on the default CoAP port or otherwise have been configured or 1558 discovered using some general service discovery mechanism such as DNS 1559 Service Discovery (DNS-SD) [I-D.cheshire-dnsext-dns-sd]. 1561 Resource discovery in CoAP is accomplished through the use of well- 1562 known resources which describe the links offered by a CoAP server. 1563 CoAP defines a well-known URI for discovery: "/.well-known/r" 1564 [RFC5785]. For example, the query [GET /.well-known/r] returns a 1565 list of links (representing resources) available from the queried 1566 CoAP server. A query such as [GET /.well-known/r?n=Voltage] returns 1567 the resources with the name Voltage. 1569 3.7. Other Applications 1571 There are many applications that rely on the IP infrastructure, but 1572 are not properly thought of as part of the IP infrastructure itself. 1573 These applications may be useful in the context of the Smart Grid. 1574 The choices made when constructing a profile of the Internet Profile 1575 Suite may impact how such applications could be used. Some of them, 1576 not by any means an exhaustive list, are discussed here. 1578 3.7.1. Session Initiation Protocol 1580 The Session Initiation Protocol 1581 [RFC3261][RFC3265][RFC3853][RFC4320][RFC4916][RFC5393][RFC5621] is an 1582 application layer control (signaling) protocol for creating, 1583 modifying and terminating multimedia sessions on the Internet, meant 1584 to be more scalable than H.323. Multimedia sessions can be voice, 1585 video, instant messaging, shared data, and/or subscriptions of 1586 events. SIP can run on top of TCP, UDP, SCTP, or TLS over TCP. SIP 1587 is independent of the transport layer, and independent of the 1588 underlying IPv4/v6 version. In fact, the transport protocol used can 1589 change as the SIP message traverses SIP entities from source to 1590 destination. 1592 SIP itself does not choose whether a session is voice or video, nor 1593 does it identify the actual endpoints' IP addresses. The SDP: 1594 Session Description Protocol [RFC4566] is intended for those 1595 purposes. Within the SDP, which is transported by SIP, codecs are 1596 offered and accepted (or not), the port number and IP address is 1597 decided for where each endpoint wants to receive their Real-time 1598 Transport Protocol (RTP) [RFC3550] packets. The introduction of 1599 Network Address Translation (NAT) technology into the profile, 1600 whether IPv4/IPv4, IPv4/IPv as described in Section 3.2.1.3, or IPv6/ 1601 IPv6, increases the complexity of SIP/SDP deployment. This is 1602 further discussed in [RFC2993] and [RFC5626]. 1604 3.7.2. Extensible Messaging and Presence Protocol 1606 The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is a 1607 protocol for streaming Extensible Markup Language (XML) elements in 1608 order to exchange structured information in close to real time 1609 between any two network endpoints. Since XMPP provides a 1610 generalized, extensible framework for exchanging XML data, it has 1611 been proposed as an application structure for interchange between 1612 embedded devices and sensors. It is currently used for Instant 1613 Messaging and Presence [RFC6121] and a wide variety of real-time 1614 communication modes. These include multi-user chat, publish- 1615 subscribe, alerts and notifications, service discovery, multimedia 1616 session management, device configuration, and remote procedure calls. 1617 XMPP supports channel encryption using TLS [RFC5246] and strong 1618 authentication (including PKIX certificate authentication) using SASL 1619 [RFC4422]. It also makes use of Unicode-compliant addresses and 1620 UTF-8 [RFC3629] data exchange for internationalization. 1622 XMPP allows for End-to-End Signing and Object Encryption [RFC3923], 1623 access to objects named using Uniform Resource Names (URN) [RFC4854], 1624 and the use of Internationalized Resource Identifiers (IRIs) and 1625 Uniform Resource Identifiers (URIs) [RFC5122], and the presentation 1626 of Notifications [RFC5437]. 1628 3.7.3. Calendaring 1630 Internet calendaring, as implemented in Apple iCal, Microsoft Outlook 1631 and Entourage, and Google Calendar, is specified in Internet 1632 Calendaring and Scheduling Core Object Specification (iCalendar) 1633 [RFC5545] and is in the process of being updated to an XML schema in 1634 iCalendar XML Representation [I-D.daboo-et-al-icalendar-in-xml] 1635 Several protocols exist to carry calendar events, including iCalendar 1636 Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the 1637 Message-Based Interoperability Protocol (iMIP) [RFC6047] , and open 1638 source work on the Atom Publishing Protocol [RFC5023]. 1640 4. A simplified view of the business architecture 1642 The Internet is a network of networks in which networks are 1643 interconnected in specific ways and are independently operated. It 1644 is important to note that the underlying Internet architecture puts 1645 no restrictions on the ways that networks are interconnected; 1646 interconnection is a business decision. As such, the Internet 1647 interconnection architecture can be thought of as a "business 1648 structure" for the Internet. 1650 Central to the Internet business structure are the networks that 1651 provide connectivity to other networks, called "Transit Networks". 1652 These networks sell bulk bandwidth and routing services to each other 1653 and to other networks as customers. Around the periphery of the 1654 transit network are companies, schools, and other networks that 1655 provide services directly to individuals. These might generally be 1656 divided into "Enterprise Networks" and "Access Networks"; Enterprise 1657 networks provide "free" connectivity to their own employees or 1658 members, and also provide them a set of services including electronic 1659 mail, web services, and so on. Access Networks sell broadband 1660 connectivity (DSL, Cable Modem, 802.11 wireless or 3GPP wireless), or 1661 "dial" services including PSTN dial-up and ISDN, to subscribers. The 1662 subscribers are typically either residential or small office/home 1663 office (SOHO) customers. Residential customers are generally 1664 entirely dependent on their access provider for all services, while a 1665 SOHO buys some services from the access provider and may provide 1666 others for itself. Networks that sell transit services to nobody 1667 else - SOHO, residential, and enterprise networks - are generally 1668 refereed to as "edge networks"; Transit Networks are considered to be 1669 part of the "core" of the Internet, and access networks are between 1670 the two. This general structure is depicted in Figure 3. 1672 ------ ------ 1673 / \ / \ 1674 /--\ / \ / \ 1675 |SOHO|---+ Access | |Enterprise| 1676 \--/ | Service | | Network | 1677 /--\ | Provider| | | 1678 |Home|---+ | ------ | | 1679 \--/ \ +---+ +---+ / 1680 \ / / \ \ / 1681 ------ | Transit | ------ 1682 | Service | 1683 | Provider | 1684 | | 1685 \ / 1686 \ / 1687 ------ 1689 Figure 3: Conceptual model of Internet businesses 1691 A specific example is shown in a traceroute from a home to a nearby 1692 school. Internet connectivity in Figure 4 passes through 1694 o The home network, 1696 o Cox Communications, an Access Network using Cable Modem 1697 technology, 1699 o TransitRail, a commodity peering service for research and 1700 education (R&E) networks, 1702 o Corporation for Education Network Initiatives in California 1703 (CENIC), a transit provider for educational networks, and 1705 o the University of California at Santa Barbara, which in this 1706 context might be viewed as an access network for its students and 1707 faculty or as an enterprise network. 1709 fred% traceroute www.ucsb.edu 1710 traceroute to web.ucsb.edu (128.111.24.41), 1711 64 hops max, 40 byte packets 1712 1 fred-vpn (10.32.244.217) 1.560 ms 1.108 ms 1.133 ms 1713 2 wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1) 12.540 ms ... 1714 3 68.6.13.101 ... 1715 4 68.6.13.129 ... 1716 5 langbbr01-as0.r2.la.cox.net ... 1717 6 calren46-cust.lsanca01.transitrail.net ... 1718 7 dc-lax-core1--lax-peer1-ge.cenic.net ... 1719 8 dc-lax-agg1--lax-core1-ge.cenic.net ... 1720 9 dc-ucsb--dc-lax-dc2.cenic.net ... 1721 10 r2--r1--1.commserv.ucsb.edu ... 1722 11 574-c--r2--2.commserv.ucsb.edu ... 1723 12 * * * 1725 Figure 4: Traceroute from residential customer to educational 1726 institution 1728 Another specific example could be shown in a traceroute from the home 1729 through a Virtual Private Network (VPN tunnel) from the home, 1730 crossing Cox Cable (an Access Network) and Pacific Bell (a Transit 1731 Network), and terminating in Cisco Systems (an Enterprise Network); a 1732 traceroute of the path doesn't show that as it is invisible within 1733 the VPN and the contents of the VPN are invisible, due to encryption, 1734 to the networks on the path. Instead, the traceroute in Figure 5 is 1735 entirely within Cisco's internal network. 1737 fred% traceroute irp-view13 1738 traceroute to irp-view13.cisco.com (171.70.120.60), 1739 64 hops max, 40 byte packets 1740 1 fred-vpn (10.32.244.217) 2.560 ms 1.100 ms 1.198 ms 1741 1742 2 **** 1743 3 sjc24-00a-gw2-ge2-2 (10.34.251.137) 26.298 ms... 1744 4 sjc23-a5-gw2-g2-1 (10.34.250.78) 25.214 ms ... 1745 5 sjc20-a5-gw1 (10.32.136.21) 23.205 ms ... 1746 6 sjc12-abb4-gw1-t2-7 (10.32.0.189) 46.028 ms ... 1747 7 sjc5-sbb4-gw1-ten8-2 (171.*.*.*) 26.700 ms ... 1748 8 sjc12-dc5-gw2-ten3-1 ... 1749 9 sjc5-dc4-gw1-ten8-1 ... 1750 10 irp-view13 ... 1752 Figure 5: Traceroute across VPN 1754 Note that in both cases, the home network uses private address space 1755 [RFC1918] while other networks generally use public address space, 1756 and that three middleware technologies are in use here. These are 1757 the uses of a firewall, a Network Address Translator (NAT), and a 1758 Virtual Private Network (VPN). 1760 Firewalls are generally sold as and considered by many to be a 1761 security technology. This is based on the fact that a firewall 1762 imposes a border between two administrative domains. Typically, a 1763 firewall will be deployed between a residential, SOHO, or enterprise 1764 network and its access or transit provider. In its essence, a 1765 firewall is a data diode, imposing a policy on what sessions may pass 1766 between a protected domain and the rest of the Internet. Simple 1767 policies generally permit sessions to be originated from the 1768 protected network but not from the outside; more complex policies may 1769 permit additional sessions from the outside, as electronic mail to a 1770 mail server or a web session to a web server, and may prevent certain 1771 applications from global access even though they are originated from 1772 the inside. 1774 Note that the effectiveness of firewalls remains controversial. 1775 While network managers often insist on deploying firewalls as they 1776 impose a boundary, others point out that their value as a security 1777 solution is debatable. This is because most attacks come from behind 1778 the firewall. In addition, firewalls do not protect against 1779 application layer attacks such as viruses carried in email. Thus, as 1780 a security solution, firewalls are justified as a layer in defense in 1781 depth. That is, while an end system must in the end be responsible 1782 for its own security, a firewall can inhibit or prevent certain kinds 1783 of attacks, for example the consumption of CPU time on a critical 1784 server. 1786 Key documents describing firewall technology and the issues it poses 1787 include: 1789 o IP Multicast and Firewalls [RFC2588] 1791 o Benchmarking Terminology for Firewall Performance [RFC2647] 1793 o Behavior of and Requirements for Internet Firewalls [RFC2979] 1795 o Benchmarking Methodology for Firewall Performance [RFC3511] 1797 o Mobile IPv6 and Firewalls: Problem Statement [RFC4487] 1799 o NAT and Firewall Traversal Issues of Host Identity Protocol 1800 Communication [RFC5207] 1802 Network Address Translation is a technology that was developed in 1803 response to ISP behaviors in the mid-1990's; when [RFC1918] was 1804 published, many ISPs started handing out single or small numbers of 1805 addresses, and edge networks were forced to translate. In time, this 1806 became considered a good thing, or at least not a bad thing; it 1807 amplified the public address space, and it was sold as if it were a 1808 firewall. It of course is not; while traditional dynamic NATs only 1809 translate between internal and external session address/port tuples 1810 during the detected duration of the session, that session state may 1811 exist in the network much longer than it exists on the end system, 1812 and as a result constitutes an attack vector. The design, value, and 1813 limitations of network address translation are described in: 1815 o IP Network Address Translator Terminology and Considerations 1816 [RFC2663] 1818 o Traditional IP Network Address Translator [RFC3022] 1820 o Protocol Complications with the IP Network Address Translator 1821 [RFC3027] 1823 o Network Address Translator Friendly Application Design Guidelines 1824 [RFC3235] 1826 o IAB Considerations for Network Address Translation [RFC3424] 1828 o IPsec-Network Address Translation Compatibility Requirements 1829 [RFC3715] 1831 o Network Address Translation Behavioral Requirements for Unicast 1832 UDP [RFC4787] 1834 o State of Peer-to-Peer Communication across Network Address 1835 Translators [RFC5128] 1837 o IP Multicast Requirements for a Network Address Translator and a 1838 Network Address Port Translator [RFC5135] 1840 Virtual Private Networks come in many forms; what they have in common 1841 is that they are generally tunneled over the internet backbone, so 1842 that as in Figure 5, connectivity appears to be entirely within the 1843 edge network although it is in fact across a service provider's 1844 network. Examples include IPsec tunnel-mode encrypted tunnels, IP- 1845 in-IP or GRE tunnels and MPLS LSPs [RFC3031][RFC3032]. . 1847 5. IANA Considerations 1849 This memo asks the IANA for no new parameters. 1851 Note to RFC Editor: This section will have served its purpose if it 1852 correctly tells IANA that no new assignments or registries are 1853 required, or if those assignments or registries are created during 1854 the RFC publication process. From the author"s perspective, it may 1855 therefore be removed upon publication as an RFC at the RFC Editor's 1856 discretion. 1858 6. Security Considerations 1860 Security is addressed in some detail in Section 2.2 and Section 3.1. 1862 7. Acknowledgements 1864 Review comments were made by Adrian Farrel, Andrew Yourtchenko, Ashok 1865 Narayanan, Bernie Volz, Chris Lonvick, Dan Romascanu, Dave McGrew, 1866 Dave Oran, David Harrington, David Su, Don Sturek, Francis Cleveland, 1867 Hemant Singh, James Polk, Jari Arkko, John Meylor, Joseph Salowey, 1868 Julien Abeille, Kerry Lynn, Lars Eggert, Magnus Westerlund, Murtaza 1869 Chiba, Paul Duffy, Paul Hoffman, Peter Saint-Andre, Ralph Droms, 1870 Robert Sparks, Russ White, Sean Turner, Sheila Frankel, Stephen 1871 Farrell, Tim Polk, Toerless Eckert, Tom Herbst, Vint Cerf, and 1872 Yoshihiro Ohba. Several suggested text, which was very useful, as 1873 the authors don't claim to know half as much as their reviewers 1874 collectively do. 1876 8. References 1877 8.1. Normative References 1879 [RFC1122] Braden, R., "Requirements for Internet Hosts - 1880 Communication Layers", STD 3, RFC 1122, October 1989. 1882 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1883 and Support", STD 3, RFC 1123, October 1989. 1885 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1886 RFC 1812, June 1995. 1888 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 1889 April 2006. 1891 8.2. Informative References 1893 [I-D.arkko-ipv6-transition-guidelines] 1894 Arkko, J. and F. Baker, "Guidelines for Using IPv6 1895 Transition Mechanisms during IPv6 Deployment", 1896 draft-arkko-ipv6-transition-guidelines-14 (work in 1897 progress), December 2010. 1899 [I-D.cheshire-dnsext-dns-sd] 1900 Cheshire, S. and M. Krochmal, "DNS-Based Service 1901 Discovery", draft-cheshire-dnsext-dns-sd-10 (work in 1902 progress), February 2011. 1904 [I-D.cheshire-dnsext-multicastdns] 1905 Cheshire, S. and M. Krochmal, "Multicast DNS", 1906 draft-cheshire-dnsext-multicastdns-14 (work in progress), 1907 February 2011. 1909 [I-D.daboo-et-al-icalendar-in-xml] 1910 Daboo, C., Douglass, M., and S. Lees, "xCal: The XML 1911 format for iCalendar", 1912 draft-daboo-et-al-icalendar-in-xml-08 (work in progress), 1913 April 2011. 1915 [I-D.ietf-6lowpan-hc] 1916 Hui, J. and P. Thubert, "Compression Format for IPv6 1917 Datagrams in Low Power and Lossy Networks (6LoWPAN)", 1918 draft-ietf-6lowpan-hc-15 (work in progress), 1919 February 2011. 1921 [I-D.ietf-6man-node-req-bis] 1922 Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 1923 Requirements RFC 4294-bis", 1924 draft-ietf-6man-node-req-bis-08 (work in progress), 1925 March 2011. 1927 [I-D.ietf-behave-dns64] 1928 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 1929 "DNS64: DNS extensions for Network Address Translation 1930 from IPv6 Clients to IPv4 Servers", 1931 draft-ietf-behave-dns64-11 (work in progress), 1932 October 2010. 1934 [I-D.ietf-behave-v6v4-framework] 1935 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 1936 IPv4/IPv6 Translation", 1937 draft-ietf-behave-v6v4-framework-10 (work in progress), 1938 August 2010. 1940 [I-D.ietf-behave-v6v4-xlate] 1941 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 1942 Algorithm", draft-ietf-behave-v6v4-xlate-23 (work in 1943 progress), September 2010. 1945 [I-D.ietf-behave-v6v4-xlate-stateful] 1946 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 1947 NAT64: Network Address and Protocol Translation from IPv6 1948 Clients to IPv4 Servers", 1949 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 1950 progress), July 2010. 1952 [I-D.ietf-core-coap] 1953 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 1954 "Constrained Application Protocol (CoAP)", 1955 draft-ietf-core-coap-05 (work in progress), March 2011. 1957 [I-D.ietf-dime-rfc3588bis] 1958 Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 1959 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-26 1960 (work in progress), January 2011. 1962 [I-D.ietf-manet-dymo] 1963 Chakeres, I. and C. Perkins, "Dynamic MANET On-demand 1964 (DYMO) Routing", draft-ietf-manet-dymo-21 (work in 1965 progress), July 2010. 1967 [I-D.ietf-oauth-v2] 1968 Hammer-Lahav, E., Recordon, D., and D. Hardt, "The OAuth 1969 2.0 Authorization Protocol", draft-ietf-oauth-v2-15 (work 1970 in progress), April 2011. 1972 [I-D.ietf-opsec-ip-security] 1973 Gont, F., "Security Assessment of the Internet Protocol 1974 version 4", draft-ietf-opsec-ip-security-07 (work in 1975 progress), April 2011. 1977 [I-D.ietf-roll-rpl] 1978 Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., 1979 Kelsey, R., Levis, P., Pister, K., Struik, R., and J. 1980 Vasseur, "RPL: IPv6 Routing Protocol for Low power and 1981 Lossy Networks", draft-ietf-roll-rpl-19 (work in 1982 progress), March 2011. 1984 [I-D.ietf-tcpm-tcp-security] 1985 Gont, F., "Security Assessment of the Transmission Control 1986 Protocol (TCP)", draft-ietf-tcpm-tcp-security-02 (work in 1987 progress), January 2011. 1989 [I-D.ietf-tls-rfc4347-bis] 1990 Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1991 Security version 1.2", draft-ietf-tls-rfc4347-bis-05 (work 1992 in progress), March 2011. 1994 [I-D.lear-abfab-arch] 1995 Howlett, J., Hartman, S., Tschofenig, H., and E. Lear, 1996 "Application Bridging for Federated Access Beyond Web 1997 (ABFAB) Architecture", draft-lear-abfab-arch-02 (work in 1998 progress), March 2011. 2000 [I-D.mcgrew-tls-aes-ccm-ecc] 2001 McGrew, D., Bailey, D., Campagna, M., and R. Dugal, "AES- 2002 CCM ECC Cipher Suites for TLS", 2003 draft-mcgrew-tls-aes-ccm-ecc-01 (work in progress), 2004 January 2011. 2006 [IEC61850] 2007 Wikipedia, "Wikipedia Article: IEC 61850 2008 http://en.wikipedia.org/wiki/IEC_61850". 2010 [IEC62351-3] 2011 International Electrotechnical Commission Technical 2012 Committee 57, "POWER SYSTEMS MANAGEMENT AND ASSOCIATED 2013 INFORMATION EXCHANGE. DATA AND COMMUNICATIONS SECURITY -- 2014 Part 3: Communication network and system security Profiles 2015 including TCP/IP", May 2007. 2017 [IEEE802.1X] 2018 Institute of Electrical and Electronics Engineers, "IEEE 2019 Standard for Local and Metropolitan Area Networks - Port 2020 based Network Access Control", IEEE Standard 802.1X-2010, 2021 February 2010. 2023 [Model] SGIP, "Smart Grid Architecture Committee: Conceptual Model 2024 White Paper http://collaborate.nist.gov/twiki-sggrid/pub/ 2025 SmartGrid/SGIPConceptualModelDevelopmentSGAC/ 2026 Smart_Grid_Conceptual_Model_20100420.doc". 2028 [RESTFUL] Fielding, "Architectural Styles and the Design of Network- 2029 based Software Architectures", 2000. 2031 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2032 August 1980. 2034 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2035 September 1981. 2037 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 2038 RFC 792, September 1981. 2040 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 2041 RFC 793, September 1981. 2043 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 2044 converting network protocol addresses to 48.bit Ethernet 2045 address for transmission on Ethernet hardware", STD 37, 2046 RFC 826, November 1982. 2048 [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams 2049 over Ethernet networks", STD 41, RFC 894, April 1984. 2051 [RFC1006] Rose, M. and D. Cass, "ISO transport services on top of 2052 the TCP: Version 3", STD 35, RFC 1006, May 1987. 2054 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 2055 STD 13, RFC 1034, November 1987. 2057 [RFC1035] Mockapetris, P., "Domain names - implementation and 2058 specification", STD 13, RFC 1035, November 1987. 2060 [RFC1058] Hedrick, C., "Routing Information Protocol", RFC 1058, 2061 June 1988. 2063 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 2064 RFC 1112, August 1989. 2066 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 2067 dual environments", RFC 1195, December 1990. 2069 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 2070 (IPCP)", RFC 1332, May 1992. 2072 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 2073 RFC 1661, July 1994. 2075 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 2076 E. Lear, "Address Allocation for Private Internets", 2077 BCP 5, RFC 1918, February 1996. 2079 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 2080 RFC 1964, June 1996. 2082 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 2083 January 1997. 2085 [RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on top 2086 of TCP (ITOT)", RFC 2126, March 1997. 2088 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 2089 RFC 2131, March 1997. 2091 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 2092 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 2093 RFC 2136, April 1997. 2095 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 2097 [RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson, "IETF 2098 Criteria for Evaluating Reliable Multicast Transport and 2099 Application Protocols", RFC 2357, June 1998. 2101 [RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, 2102 November 1998. 2104 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2105 (IPv6) Specification", RFC 2460, December 1998. 2107 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 2108 Networks", RFC 2464, December 1998. 2110 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2111 "Definition of the Differentiated Services Field (DS 2112 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2113 December 1998. 2115 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2116 and W. Weiss, "An Architecture for Differentiated 2117 Services", RFC 2475, December 1998. 2119 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 2120 and R. Wheeler, "A Method for Transmitting PPP Over 2121 Ethernet (PPPoE)", RFC 2516, February 1999. 2123 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 2124 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 2125 March 1999. 2127 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 2128 Adams, "X.509 Internet Public Key Infrastructure Online 2129 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 2131 [RFC2588] Finlayson, R., "IP Multicast and Firewalls", RFC 2588, 2132 May 1999. 2134 [RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, 2135 "Service Location Protocol, Version 2", RFC 2608, 2136 June 1999. 2138 [RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH", RFC 2615, 2139 June 1999. 2141 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 2142 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 2143 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 2145 [RFC2647] Newman, D., "Benchmarking Terminology for Firewall 2146 Performance", RFC 2647, August 1999. 2148 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 2149 Translator (NAT) Terminology and Considerations", 2150 RFC 2663, August 1999. 2152 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 2153 Listener Discovery (MLD) for IPv6", RFC 2710, 2154 October 1999. 2156 [RFC2743] Linn, J., "Generic Security Service Application Program 2157 Interface Version 2, Update 1", RFC 2743, January 2000. 2159 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 2160 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2161 March 2000. 2163 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 2164 "Remote Authentication Dial In User Service (RADIUS)", 2165 RFC 2865, June 2000. 2167 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 2168 Firewalls", RFC 2979, October 2000. 2170 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 2171 November 2000. 2173 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 2174 Update", RFC 3007, November 2000. 2176 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 2177 Address Translator (Traditional NAT)", RFC 3022, 2178 January 2001. 2180 [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications 2181 with the IP Network Address Translator", RFC 3027, 2182 January 2001. 2184 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 2185 Label Switching Architecture", RFC 3031, January 2001. 2187 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 2188 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 2189 Encoding", RFC 3032, January 2001. 2191 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2192 of Explicit Congestion Notification (ECN) to IP", 2193 RFC 3168, September 2001. 2195 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 2196 Application Design Guidelines", RFC 3235, January 2002. 2198 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2199 A., Peterson, J., Sparks, R., Handley, M., and E. 2200 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2201 June 2002. 2203 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 2204 Event Notification", RFC 3265, June 2002. 2206 [RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup 2207 Language) XML-Signature Syntax and Processing", RFC 3275, 2208 March 2002. 2210 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 2211 and M. Carney, "Dynamic Host Configuration Protocol for 2212 IPv6 (DHCPv6)", RFC 3315, July 2003. 2214 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 2215 Thyagarajan, "Internet Group Management Protocol, Version 2216 3", RFC 3376, October 2002. 2218 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 2219 Architecture for Describing Simple Network Management 2220 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 2221 December 2002. 2223 [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, 2224 "Message Processing and Dispatching for the Simple Network 2225 Management Protocol (SNMP)", STD 62, RFC 3412, 2226 December 2002. 2228 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 2229 Management Protocol (SNMP) Applications", STD 62, 2230 RFC 3413, December 2002. 2232 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 2233 (USM) for version 3 of the Simple Network Management 2234 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 2236 [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 2237 Access Control Model (VACM) for the Simple Network 2238 Management Protocol (SNMP)", STD 62, RFC 3415, 2239 December 2002. 2241 [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the 2242 Simple Network Management Protocol (SNMP)", STD 62, 2243 RFC 3416, December 2002. 2245 [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network 2246 Management Protocol (SNMP)", STD 62, RFC 3417, 2247 December 2002. 2249 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 2250 Simple Network Management Protocol (SNMP)", STD 62, 2251 RFC 3418, December 2002. 2253 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 2254 Self-Address Fixing (UNSAF) Across Network Address 2255 Translation", RFC 3424, November 2002. 2257 [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 2258 Layer Security over Stream Control Transmission Protocol", 2259 RFC 3436, December 2002. 2261 [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, 2262 M., and J. Crowcroft, "The Use of Forward Error Correction 2263 (FEC) in Reliable Multicast", RFC 3453, December 2002. 2265 [RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. Martin, 2266 "Benchmarking Methodology for Firewall Performance", 2267 RFC 3511, April 2003. 2269 [RFC3522] Ludwig, R. and M. Meyer, "The Eifel Detection Algorithm 2270 for TCP", RFC 3522, April 2003. 2272 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2273 Jacobson, "RTP: A Transport Protocol for Real-Time 2274 Applications", STD 64, RFC 3550, July 2003. 2276 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 2277 Demand Distance Vector (AODV) Routing", RFC 3561, 2278 July 2003. 2280 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 2281 Multicast (SSM)", RFC 3569, July 2003. 2283 [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 2284 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 2286 [RFC3590] Haberman, B., "Source Address Selection for the Multicast 2287 Listener Discovery (MLD) Protocol", RFC 3590, 2288 September 2003. 2290 [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing 2291 Protocol (OLSR)", RFC 3626, October 2003. 2293 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2294 10646", STD 63, RFC 3629, November 2003. 2296 [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation 2297 (NAT) Compatibility Requirements", RFC 3715, March 2004. 2299 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 2300 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 2302 [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and 2303 G. Fairhurst, "The Lightweight User Datagram Protocol 2304 (UDP-Lite)", RFC 3828, July 2004. 2306 [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) 2307 Requirement for the Session Initiation Protocol (SIP)", 2308 RFC 3853, July 2004. 2310 [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption 2311 for the Extensible Messaging and Presence Protocol 2312 (XMPP)", RFC 3923, October 2004. 2314 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 2315 Neighbor Discovery (SEND)", RFC 3971, March 2005. 2317 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 2318 Independent Multicast - Dense Mode (PIM-DM): Protocol 2319 Specification (Revised)", RFC 3973, January 2005. 2321 [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible 2322 Authentication Protocol (EAP) Method Requirements for 2323 Wireless LANs", RFC 4017, March 2005. 2325 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2326 Rose, "DNS Security Introduction and Requirements", 2327 RFC 4033, March 2005. 2329 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2330 Rose, "Resource Records for the DNS Security Extensions", 2331 RFC 4034, March 2005. 2333 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 2334 Rose, "Protocol Modifications for the DNS Security 2335 Extensions", RFC 4035, March 2005. 2337 [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to 2338 Protect Firmware Packages", RFC 4108, August 2005. 2340 [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The 2341 Kerberos Network Authentication Service (V5)", RFC 4120, 2342 July 2005. 2344 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 2345 Version 5 Generic Security Service Application Program 2346 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 2347 July 2005. 2349 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 2350 "Internet X.509 Public Key Infrastructure Certificate 2351 Management Protocol (CMP)", RFC 4210, September 2005. 2353 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 2354 for IPv6 Hosts and Routers", RFC 4213, October 2005. 2356 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 2357 Transport Layer Protocol", RFC 4253, January 2006. 2359 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 2360 Protocol 4 (BGP-4)", RFC 4271, January 2006. 2362 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2363 Architecture", RFC 4291, February 2006. 2365 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2366 Internet Protocol", RFC 4301, December 2005. 2368 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 2369 December 2005. 2371 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 2372 RFC 4303, December 2005. 2374 [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the 2375 Internet Key Exchange Version 2 (IKEv2)", RFC 4307, 2376 December 2005. 2378 [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the 2379 Session Initiation Protocol's (SIP) Non-INVITE 2380 Transaction", RFC 4320, January 2006. 2382 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2383 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 2385 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2386 Security", RFC 4347, April 2006. 2388 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 2389 Networks (VPNs)", RFC 4364, February 2006. 2391 [RFC4410] Pullen, M., Zhao, F., and D. Cohen, "Selectively Reliable 2392 Multicast Protocol (SRMP)", RFC 4410, February 2006. 2394 [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and 2395 Security Layer (SASL)", RFC 4422, June 2006. 2397 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 2398 Message Protocol (ICMPv6) for the Internet Protocol 2399 Version 6 (IPv6) Specification", RFC 4443, March 2006. 2401 [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile 2402 IPv6 and Firewalls: Problem Statement", RFC 4487, 2403 May 2006. 2405 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. 2406 Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites 2407 for Transport Layer Security (TLS)", RFC 4492, May 2006. 2409 [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial 2410 Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. 2412 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2413 Description Protocol", RFC 4566, July 2006. 2415 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 2416 Guidelines for DiffServ Service Classes", RFC 4594, 2417 August 2006. 2419 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 2420 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 2421 Protocol Specification (Revised)", RFC 4601, August 2006. 2423 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 2424 Group Management Protocol Version 3 (IGMPv3) and Multicast 2425 Listener Discovery Protocol Version 2 (MLDv2) for Source- 2426 Specific Multicast", RFC 4604, August 2006. 2428 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 2429 IP", RFC 4607, August 2006. 2431 [RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific 2432 Protocol Independent Multicast in 232/8", BCP 120, 2433 RFC 4608, August 2006. 2435 [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap 2436 for Transmission Control Protocol (TCP) Specification 2437 Documents", RFC 4614, September 2006. 2439 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 2440 December 2006. 2442 [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF 2443 Configuration Protocol over Secure SHell (SSH)", RFC 4742, 2444 December 2006. 2446 [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access 2447 Protocol (SOAP)", RFC 4743, December 2006. 2449 [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over 2450 the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, 2451 December 2006. 2453 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 2454 "Multiprotocol Extensions for BGP-4", RFC 4760, 2455 January 2007. 2457 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 2458 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 2459 RFC 4787, January 2007. 2461 [RFC4835] Manral, V., "Cryptographic Algorithm Implementation 2462 Requirements for Encapsulating Security Payload (ESP) and 2463 Authentication Header (AH)", RFC 4835, April 2007. 2465 [RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace 2466 for Extensions to the Extensible Messaging and Presence Pr 2467 otocol (XMPP)", RFC 4854, April 2007. 2469 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2470 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2471 September 2007. 2473 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2474 Address Autoconfiguration", RFC 4862, September 2007. 2476 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 2477 Protocol (SIP)", RFC 4916, June 2007. 2479 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2480 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2481 Overview, Assumptions, Problem Statement, and Goals", 2482 RFC 4919, August 2007. 2484 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 2485 Extensions for Stateless Address Autoconfiguration in 2486 IPv6", RFC 4941, September 2007. 2488 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2489 "Transmission of IPv6 Packets over IEEE 802.15.4 2490 Networks", RFC 4944, September 2007. 2492 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 2493 RFC 4960, September 2007. 2495 [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common 2496 Mitigations", RFC 4987, August 2007. 2498 [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing 2499 Protocol", RFC 5023, October 2007. 2501 [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. 2502 Kozuka, "Stream Control Transmission Protocol (SCTP) 2503 Dynamic Address Reconfiguration", RFC 5061, 2504 September 2007. 2506 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 2507 PPP", RFC 5072, September 2007. 2509 [RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers 2510 (IRIs) and Uniform Resource Identifiers (URIs) for the 2511 Extensible Messaging and Presence Protocol (XMPP)", 2512 RFC 5122, February 2008. 2514 [RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to- 2515 Peer (P2P) Communication across Network Address 2516 Translators (NATs)", RFC 5128, March 2008. 2518 [RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a 2519 Network Address Translator (NAT) and a Network Address 2520 Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. 2522 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 2523 Yegin, "Protocol for Carrying Authentication for Network 2524 Access (PANA)", RFC 5191, May 2008. 2526 [RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and 2527 Firewall Traversal Issues of Host Identity Protocol (HIP) 2528 Communication", RFC 5207, April 2008. 2530 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 2531 Authentication Protocol", RFC 5216, March 2008. 2533 [RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over 2534 the Datagram Congestion Control Protocol (DCCP)", 2535 RFC 5238, May 2008. 2537 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 2538 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 2540 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 2541 (CMC)", RFC 5272, June 2008. 2543 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 2544 Notifications", RFC 5277, July 2008. 2546 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 2547 Housley, R., and W. Polk, "Internet X.509 Public Key 2548 Infrastructure Certificate and Certificate Revocation List 2549 (CRL) Profile", RFC 5280, May 2008. 2551 [RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- 2552 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 2553 August 2008. 2555 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 2556 October 2008. 2558 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2559 for IPv6", RFC 5340, July 2008. 2561 [RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, 2562 "Addressing an Amplification Vulnerability in Session 2563 Initiation Protocol (SIP) Forking Proxies", RFC 5393, 2564 December 2008. 2566 [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines 2567 for Application Designers", BCP 145, RFC 5405, 2568 November 2008. 2570 [RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile 2571 for Transport Layer Security (TLS)", RFC 5430, March 2009. 2573 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 2574 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 2575 RFC 5433, February 2009. 2577 [RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification 2578 Mechanism: Extensible Messaging and Presence Protocol 2579 (XMPP)", RFC 5437, January 2009. 2581 [RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", 2582 RFC 5539, May 2009. 2584 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 2585 Core Object Specification (iCalendar)", RFC 5545, 2586 September 2009. 2588 [RFC5546] Daboo, C., "iCalendar Transport-Independent 2589 Interoperability Protocol (iTIP)", RFC 5546, 2590 December 2009. 2592 [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, 2593 "Routing Requirements for Urban Low-Power and Lossy 2594 Networks", RFC 5548, May 2009. 2596 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 2597 Infrastructures (6rd)", RFC 5569, January 2010. 2599 [RFC5621] Camarillo, G., "Message Body Handling in the Session 2600 Initiation Protocol (SIP)", RFC 5621, September 2009. 2602 [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- 2603 Initiated Connections in the Session Initiation Protocol 2604 (SIP)", RFC 5626, October 2009. 2606 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 2607 RFC 5652, September 2009. 2609 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 2610 "Industrial Routing Requirements in Low-Power and Lossy 2611 Networks", RFC 5673, October 2009. 2613 [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion 2614 Control", RFC 5681, September 2009. 2616 [RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote 2617 Procedure Call (RPC) for NETCONF", RFC 5717, 2618 December 2009. 2620 [RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, 2621 "NACK-Oriented Reliable Multicast (NORM) Transport 2622 Protocol", RFC 5740, November 2009. 2624 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2625 Mail Extensions (S/MIME) Version 3.2 Message 2626 Specification", RFC 5751, January 2010. 2628 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 2629 Uniform Resource Identifiers (URIs)", RFC 5785, 2630 April 2010. 2632 [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation 2633 Routing Requirements in Low-Power and Lossy Networks", 2634 RFC 5826, April 2010. 2636 [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. 2637 Aggarwal, "Support of Address Families in OSPFv3", 2638 RFC 5838, April 2010. 2640 [RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, 2641 April 2010. 2643 [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, 2644 "Building Automation Routing Requirements in Low-Power and 2645 Lossy Networks", RFC 5867, June 2010. 2647 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 2648 Time Protocol Version 4: Protocol and Algorithms 2649 Specification", RFC 5905, June 2010. 2651 [RFC5932] Kato, A., Kanda, M., and S. Kanno, "Camellia Cipher Suites 2652 for TLS", RFC 5932, June 2010. 2654 [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, 2655 August 2010. 2657 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 2658 "Internet Key Exchange Protocol Version 2 (IKEv2)", 2659 RFC 5996, September 2010. 2661 [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension 2662 for EAP-Only Authentication in IKEv2", RFC 5998, 2663 September 2010. 2665 [RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax 2666 (CMS) Symmetric Key Package Content Type", RFC 6031, 2667 December 2010. 2669 [RFC6047] Melnikov, A., "iCalendar Message-Based Interoperability 2670 Protocol (iMIP)", RFC 6047, December 2010. 2672 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 2673 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 2674 October 2010. 2676 [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic 2677 Curve Cryptography Algorithms", RFC 6090, February 2011. 2679 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 2680 Protocol (XMPP): Core", RFC 6120, March 2011. 2682 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 2683 Protocol (XMPP): Instant Messaging and Presence", 2684 RFC 6121, March 2011. 2686 [SP-MULPIv3.0] 2687 CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols 2688 Interface Specification, CM-SP-MULPIv3.0-I10-090529", 2689 May 2009. 2691 [SmartGrid] 2692 Wikipedia, "Wikipedia Article: Smart Grid http:// 2693 en.wikipedia.org/w/ 2694 index.php?title=Smart_grid&oldid=415838933", 2695 February 2011. 2697 [r1822] Bolt Beranek and Newman Inc., "Interface Message Processor 2698 -- Specifications for the interconnection of a host and a 2699 IMP, Report No. 1822", January 1976. 2701 Appendix A. Example: Advanced Metering Infrastructure 2703 This appendix provides a worked example of the use of the Internet 2704 Protocol Suite in a network such as the Smart Grid's Advanced 2705 Metering Infrastructure (AMI). There are several possible models. 2707 Figure 6 shows the structure of the AMI as it reaches out towards a 2708 set of residences. In this structure, we have the home itself and 2709 its Home Area Network (HAN), the Neighborhood Area Network (NAN) that 2710 the utility uses to access the meter at the home, and the utility 2711 access network that connects a set of NANs to the utility itself. 2712 For the purposes of this discussion, assume that the NAN contains a 2713 distributed application in a set collectors, which is of course only 2714 one way the application could be implemented. 2716 --- 2717 A thermostats, appliances, etc 2718 | ------+----------------------------------- 2719 | | 2720 |"HAN" | <--- Energy Services Interface (ESI) 2721 | +---+---+ 2722 | | Meter | Meter is generally an ALG between the AMI and the HAN 2723 | +---+---+ 2724 V \ 2725 --- \ 2726 A \ | / 2727 | \ | / 2728 | "NAN" +--+-+-+---+ Likely a router but could 2729 | |Collector | be an front-end application 2730 V +----+-----+ gateway for utility 2731 --- \ 2732 A \ | / 2733 | \ | / 2734 |"AMI" +--+-+-+--+ 2735 | | AMI | 2736 | | Headend | 2737 V +---------+ 2738 --- 2740 Figure 6: The HAN, NAN, and Utility in the Advanced Metering 2741 Infrastructure 2743 There are several questions that have to be answered in describing 2744 this picture, which given possible answers yield different possible 2745 models. They include at least: 2747 o How does Demand Response work? Either: 2749 * The utility presents pricing signals to the home, 2751 * The utility presents pricing signals individual devices (e.g., 2752 a Pluggable Electric Vehicle), 2754 * The utility adjusts settings on individual appliances within 2755 the home. 2757 o How does the utility access meters at the home? 2759 * The AMI Headend manages the interfaces with the meters, 2760 collecting metering data and passing it on to the appropriate 2761 applications over the Enterprise Bus, or 2763 * Distributed application support (collectors") might access and 2764 summarize the information; this device might be managed by the 2765 utility or by a service between the utility and its customers. 2767 In implementation, these models are idealized; reality may include 2768 some aspects of each model in specified cases. 2770 The examples include: 2772 1. Appendix A.2 presumes that the HAN, the NAN, and the utility's 2773 network are separate administrative domains and speak application 2774 to application across those domains. 2776 2. Appendix A.3 repeats the first example, but presuming that the 2777 utility directly accesses appliances within the HAN from the 2778 collector". 2780 3. Appendix A.4 repeats the first example, but presuming that the 2781 collector directly forwards traffic as a router in addition to 2782 distributed application chores. Note that this case implies 2783 numerous privacy and security concerns and as such is considered 2784 a less likely deployment model. 2786 A.1. How to structure a network 2788 A key consideration in the Internet has been the development of new 2789 link layer technologies over time. The ARPANET originally used a BBN 2790 proprietary link layer called BBN 1822 [r1822]. In the late 1970's, 2791 the ARPANET switched to X.25 as an interface to the 1822 network. 2792 With the deployment of the IEEE 802 series technologies in the early 2793 1980's, IP was deployed on Ethernet (IEEE 802.3), Token Ring (IEEE 2794 802.5) and WiFi (IEEE 802.11), as well as Arcnet, serial lines of 2795 various kinds, Frame Relay, and ATM. A key issue in this evolution 2796 was that the applications developed to run on the Internet use APIs 2797 related to the IPS, and as a result require little or no change to 2798 continue to operate in a new link layer architecture or a mixture of 2799 them. 2801 The Smart Grid is likely to see a similar evolution over time. 2802 Consider the Home Area Network (HAN) as a readily understandable 2803 small network. At this juncture, technologies proposed for 2804 residential networks include IEEE P1901, various versions of IEEE 2805 802.15.4, and IEEE 802.11. It is reasonable to expect other 2806 technologies to be developed in the future. As the Zigbee Alliance 2807 has learned (and as a resulted incorporated the IPS in Smart Energy 2808 Profile 2.0), there is significant value in providing a virtual 2809 address that is mapped to interfaces or nodes attached to each of 2810 those technologies. 2812 Utility NAN 2813 / 2814 / 2815 +----+-----+ +--+ +--+ +--+ 2816 | Meter | |D1| |D2| |D3| 2817 +-----+----+ ++-+ ++-+ ++-+ 2818 | | | | 2819 ----+-+-------+----+----+---- IEEE 802.15.4 2820 | 2821 +--+---+ 2822 |Router+------/------ Residential Broadband 2823 +--+---+ 2824 | 2825 ----+---------+----+----+---- IEEE P1901 2826 | | | 2827 ++-+ ++-+ ++-+ 2828 |D4| |D5| |D6| 2829 +--+ +--+ +--+ 2830 A thermostats, appliances, etc 2831 | ------+----------------+------------------ 2832 |"HAN" | | 2833 | +---+---+ +---+---+ 2834 | |Router | | Meter | 2835 | |or EMS | | | 2836 V +---+---+ +---+---+ 2837 --- | --- \ 2838 | ^ \ | / 2839 | |"NAN" \ | / 2840 ---+--- | +--+-+-+---+ 2841 / \ | |"Pole Top"| 2842 | Internet| v +----+-----+ 2843 \ / --- 2844 ------- 2846 Figure 7: Two views of a Home Area Network 2848 There are two possible communication models within the HAN, both of 2849 which are likely to be useful. Devices may communicate directly with 2850 each other, or they may be managed by some central controller. An 2851 example of direct communications might be a light switch that 2852 directly commands a lamp to turn on or off. An example of indirect 2853 communications might be a control application in a Customer or 2854 Building that accepts telemetry from a thermostat, applies some form 2855 of policy, and controls the heating and air conditioning systems. In 2856 addition, there are high end appliances in the market today that use 2857 residential broadband to communicate with their manufacturers, and 2858 obviously the meter needs to communicate with the utility. 2860 Figure 7 shows two simple networks, one of which IEEE 802.15.4 and 2861 IEEE 1901 domains, and one of which uses an arbitrary LAN within the 2862 home, which could be IEEE 802.3/Ethernet, IEEE 802.15.4, IEEE 1901, 2863 IEEE 802.11, or anything else that made sense in context. Both show 2864 the connectivity between them as a router separate from the EMS. 2865 This is for clarity; the two could of course be incorporated into a 2866 single system, and one could imagine appliances that want to 2867 communicate with their manufacturers supporting both a HAN interface 2868 and a WiFi interface rather than depending on the router. These are 2869 all manufacturer design decisions. 2871 A.1.1. HAN Routing 2873 The HAN can be seen as communicating with two kinds of non-HAN 2874 networks. One is the home LAN, which may in turn be attached to the 2875 Internet, and will generally either derive its prefix from the 2876 upstream ISP or use a self-generated ULA. Another is the utility's 2877 NAN, which through an ESI provides utility connectivity to the HAN; 2878 in this case the HAN will be addressed by a self-generated ULA (note, 2879 however, that in some cases ESI may also provide a prefix via DHCP 2880 [RFC3315]). In addition, the HAN will have link-local addresses that 2881 can be used between neighboring nodes. In general, an HAN will be 2882 comprised of both 802.15.4, 802.11 (and possibly other) networks. 2884 The ESI is a node on the user's residential network, and will not 2885 typically provide stateful packet forwarding or firewall services 2886 between the HAN and the utility network(s). In general, the ESI is a 2887 node on the home network; in some cases, the meter may act as the 2888 ESI. However, the ESI must be capable of understanding that most 2889 home networks are not 802.15.4 enabled (rather, they are typically 2890 802.11 networks), and that it must be capable of setting up ad-hoc 2891 networks between various sensors in the home (e.g., between the meter 2892 and say, a thermostat) in the event there aren't other networks 2893 available. 2895 A.1.2. HAN Security 2897 In any network, we have a variety of threats and a variety of 2898 possible mitigations. These include, at minimum: 2900 Link Layer: Why is your machine able to talk in my network? The 2901 WiFi SSIDs often use some form of authenticated access control, 2902 which may be a simple encrypted password mechanism or may use a 2903 combination of encryption and IEEE 802.1X+EAP-TLS Authentication/ 2904 Authorization to ensure that only authorized communicants can use 2905 it. If a LAN has a router attached, the router may also implement 2906 a firewall to filter remote accesses. 2908 Network Layer: Given that your machine is authorized access to my 2909 network, why is your machine talking with my machine? IPsec is a 2910 way of ensuring that computers that can use a network are allowed 2911 to talk with each other, may also enforce confidentiality, and may 2912 provide VPN services to make a device or network appear to be part 2913 of a remote network. 2915 Application: Given that your machine is authorized access to my 2916 network and my machine, why is your application talking with my 2917 application? The fact that your machine and mine are allowed to 2918 talk for some applications doesn't mean they are allowed to for 2919 all applications. (D)TLS, https, and other such mechanisms enable 2920 an application to impose application-to-application controls 2921 similar to the network layer controls provided by IPsec. 2923 Remote Application: How do I know that the data I received is the 2924 data you sent? Especially in applications like electronic mail, 2925 where data passes through a number of intermediaries that one may 2926 or may not really want munging it (how many times have you seen a 2927 URL broken by a mail server?), we have tools (DKIM, S/MIME, and 2928 W3C XML Signatures to name a few) to provide non-repudiability and 2929 integrity verification. This may also have legal ramifications: 2930 if a record of a meter reading is to be used in billing, and the 2931 bill is disputed in court, one could imagine the court wanting 2932 proof that the record in fact came from that meter at that time 2933 and contained that data. 2935 Application-specific security: In addition, applications often 2936 provide security services of their own. The fact that I can 2937 access a file system, for example, doesn't mean that I am 2938 authorized to access everything in it; the file system may well 2939 prevent my access to some of its contents. Routing protocols like 2940 BGP obsess with the question "what statements that my peer made am 2941 I willing to believe". And monitoring protocols like SNMP may not 2942 be willing to answer every question they are asked, depending on 2943 access configuration. 2945 Devices in the HAN want controlled access to the LAN in question for 2946 obvious reasons. In addition, there should be some form of mutual 2947 authentication between devices - the lamp controller will want to 2948 know that the light switch telling it to change state is the right 2949 light switch, for example. The EMS may well want strong 2950 authentication of accesses - the parents may not want the children 2951 changing the settings, and while the utility and the customer are 2952 routinely granted access, other parties (especially parties with 2953 criminal intent) need to be excluded. 2955 A.2. Model 1: AMI with separated domains 2957 With the background given in Appendix A.1, we can now discuss the use 2958 of IP (IPv4 or IPv6) in the AMI. 2960 In this first model, consider the three domains in Figure 6 to 2961 literally be separate administrative domains, potentially operated by 2962 different entities. For example, the NAN could be a WiMAX network 2963 operated by a traditional telecom operator, the utility's network 2964 (including the collector) is its own, and the residential network is 2965 operated by the resident. In this model, while communications 2966 between the collector and the Meter are normal, the utility has no 2967 other access to appliances in the home, and the collector doesn't 2968 directly forward messages from the NAN upstream. 2970 In this case, as shown in Figure 7, it would make the most sense to 2971 design the collector, the Meter, and the EMS as hosts on the NAN - 2972 design them as systems whose applications can originate and terminate 2973 exchanges or sessions in the NAN, but not forward traffic from or to 2974 other devices. 2976 In such a configuration, Demand Response has to be performed by 2977 having the EMS accept messages such as price signals from the "pole 2978 top", apply some form of policy, and then orchestrate actions within 2979 the home. Another possibility is to have the EMS communicate with 2980 the ESI located in the meter. If the thermostat has high demand and 2981 low demand (day/night or morning/day/evening/night) settings, Demand 2982 Response might result in it moving to a lower demand setting, and the 2983 EMS might also turn off specified circuits in the home to diminish 2984 lighting. 2986 In this scenario, Quality of Service (QoS) issues reportedly arise 2987 when high precedence messages must be sent through the collector to 2988 the home; if the collector is occupied polling the meters or doing 2989 some other task, the application may not yield control of the 2990 processor to the application that services the message. Clearly, 2991 this is either an application or an Operating System problem; 2992 applications need to be designed in a manner that doesn't block high 2993 precedence messages. The collector also needs to use appropriate NAN 2994 services, if they exist, to provide the NAN QoS it needs. For 2995 example, if WiMax is in use, it might use a routine-level service for 2996 normal exchanges but a higher precedence service for these messages. 2998 A.3. Model 2: AMI with neighborhood access to the home 3000 In this second model, let's imagine that the utility directly 3001 accesses appliances within the HAN. Rather than expect an EMS to 3002 respond to price signals in Demand Response, it directly commands 3003 devices like air conditioners to change state, or throws relays on 3004 circuits to or within the home. 3006 +----------+ +--+ +--+ +--+ 3007 | Meter | |D1| |D2| |D3| 3008 +-----+----+ ++-+ ++-+ ++-+ 3009 | | | | 3010 ----+-+-------+----+----+---- IEEE 802.15.4 3011 | 3012 +--+---+ 3013 | +------/------ NAN 3014 |Router| 3015 | +------/------ Residential Broadband 3016 +--+---+ 3017 | 3018 ----+---------+----+----+---- IEEE P1901 3019 | | | 3020 ++-+ ++-+ ++-+ 3021 |D4| |D5| |D6| 3022 +--+ +--+ +--+ 3024 Figure 8: Home Area Network 3026 In this case, as shown in Figure 8, the Meter, and EMS as hosts on 3027 the HAN, and there is a router between the HAN and the NAN. 3029 As one might imagine, there are serious security considerations in 3030 this model. Traffic between the NAN and the residential broadband 3031 network should be filtered, and the issues raised in Appendix A.1.2 3032 take on a new level of meaning. One of the biggest threats may be a 3033 legal or at least a public relations issue; if the utility 3034 intentionally disables a circuit in a manner or at a time that 3035 threatens life (the resident's kidney dialysis machine is on it, or a 3036 respirator, for example) the matter might make the papers. 3037 Unauthorized access could be part of juvenile pranks or other things 3038 as well. So one really wants the appliances to only obey commands 3039 under strict authentication/authorization controls. 3041 In addition to the QoS issues raised in Appendix A.2, there is the 3042 possibility of queuing issues in the router. In such a case, the IP 3043 datagrams should probably use the Low-Latency Data Service Class 3044 described in [RFC4594], and let other traffic use the Standard 3045 Service Class or other service classes. 3047 A.4. Model 3: Collector is an IP router 3049 In this third model, the relationship between the NAN and the HAN is 3050 either as in Appendix A.2 or Appendix A.3; what is different is that 3051 the collector may be an IP router. In addition to whatever 3052 autonomous activities it is doing, it forwards traffic as an IP 3053 router in some cases. 3055 As and analogous to Appendix A.3, there are serious security 3056 considerations in this model. Traffic being forwarded should be 3057 filtered, and the issues raised in Appendix A.1.2 take on a new level 3058 of meaning - but this time at the utility mainframe. Unauthorized 3059 access is likely similar to other financially-motivated attacks that 3060 happen in the Internet, but presumably would be coming from devices 3061 in the HAN that have been co-opted in some way. One really wants the 3062 appliances to only obey commands under strict authentication/ 3063 authorization controls. 3065 In addition to the QoS issues raised in Appendix A.2, there is the 3066 possibility of queuing issues in the collector. In such a case, the 3067 IP datagrams should probably use the Low-Latency Data Service Class 3068 described in [RFC4594], and let other traffic use the Standard 3069 Service Class or other service classes. 3071 Authors' Addresses 3073 Fred Baker 3074 Cisco Systems 3075 Santa Barbara, California 93117 3076 USA 3078 Email: fred@cisco.com 3080 David Meyer 3081 Cisco Systems 3082 Eugene, Oregon 97403 3083 USA 3085 Email: dmm@cisco.com