RFC 6272
Internet Protocols for the Smart Grid
Internet Protocols for the Smart Grid ⚡💖
okay bestie, this is RFC 6272, and it's giving the Smart Grid, but make it Internet Protocol Suite 🔌✨. It's written by F. Baker and D. Meyer from Cisco Systems. It's Informational, not a Standards Track spec, so it's guidance, not a rulebook 🧚. The ISSN is 2070-1721, and it was published in June 2011 🎀. Its title block doesn't list anything it obsoletes or updates, so it doesn't replace or change any older RFCs 🌸.
Abstract
okay so the whole point of this note is to name the key infrastructure protocols of the Internet Protocol Suite that are useful for the Smart Grid 💡. The main audience is people who want help building a proper Internet Protocol Suite profile for the Smart Grid 🦋. And a profile like that is basically just picking the stuff you actually need for Smart Grid deployment out of the big picture this doc lays out 💅.
Status of This Memo
this is NOT a Standards Track spec, it's just published for info 🫶. It's still a product of the Internet Engineering Task Force (IETF) 🌈, so it reflects consensus from the IETF community and got public review. The Internet Engineering Steering Group (IESG) approved it for publication 👑. Not every IESG-approved doc is up for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious about that 🙈.
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6272 💜.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, which you can find at http://trustee.ietf.org/license-info (as in effect on the publication date). Please actually read those, bestie, because they explain your rights and restrictions for this document 🙏. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, just like the Simplified BSD License says 💖.
heads up: code pulled from this doc needs that Simplified BSD License text attached, no exceptions ⚠️
Table of Contents 🧾
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. The Internet Protocol Suite . . . . . . . . . . . . . . . . . 6
2.1. Internet Protocol Layers . . . . . . . . . . . . . . . . . 6
2.1.1. Application . . . . . . . . . . . . . . . . . . . . . 7
2.1.2. Transport . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3. Network . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.3.1. Internet Protocol . . . . . . . . . . . . . . . . 9
2.1.3.2. Lower-Layer Networks . . . . . . . . . . . . . . . 9
2.1.4. Media Layers: Physical and Link . . . . . . . . . . . 9
2.2. Security Issues . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Physical and Data Link Layer Security . . . . . . . . 10
2.2.2. Network, Transport, and Application Layer Security . . 11
2.3. Network Infrastructure . . . . . . . . . . . . . . . . . . 13
2.3.1. Domain Name System (DNS) . . . . . . . . . . . . . . . 13
2.3.2. Network Management . . . . . . . . . . . . . . . . . . 13
3. Specific Protocols . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Security Toolbox . . . . . . . . . . . . . . . . . . . . . 14
3.1.1. Authentication, Authorization, and Accounting (AAA) . 14
3.1.2. Network Layer Security . . . . . . . . . . . . . . . . 15
3.1.3. Transport Layer Security . . . . . . . . . . . . . . . 16
3.1.4. Application Layer Security . . . . . . . . . . . . . . 17
3.1.5. Secure Shell . . . . . . . . . . . . . . . . . . . . . 18
3.1.6. Key Management Infrastructures . . . . . . . . . . . . 18
3.1.6.1. PKIX . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.6.2. Kerberos . . . . . . . . . . . . . . . . . . . . . 19
3.2. Network Layer . . . . . . . . . . . . . . . . . . . . . . 19
3.2.1. IPv4/IPv6 Coexistence Advice . . . . . . . . . . . . . 19
3.2.1.1. Dual Stack Coexistence . . . . . . . . . . . . . . 19
3.2.1.2. Tunneling Mechanism . . . . . . . . . . . . . . . 20
3.2.1.3. Translation between IPv4 and IPv6 Networks . . . . 20
3.2.2. Internet Protocol Version 4 . . . . . . . . . . . . . 21
3.2.2.1. IPv4 Address Allocation and Assignment . . . . . . 22
3.2.2.2. IPv4 Unicast Routing . . . . . . . . . . . . . . . 22
3.2.2.3. IPv4 Multicast Forwarding and Routing . . . . . . 22
3.2.3. Internet Protocol Version 6 . . . . . . . . . . . . . 23
3.2.3.1. IPv6 Address Allocation and Assignment . . . . . . 23
3.2.3.2. IPv6 Routing . . . . . . . . . . . . . . . . . . . 24
3.2.4. Routing for IPv4 and IPv6 . . . . . . . . . . . . . . 24
3.2.4.1. Routing Information Protocol . . . . . . . . . . . 24
3.2.4.2. Open Shortest Path First . . . . . . . . . . . . . 24
3.2.4.3. ISO Intermediate System to Intermediate System . . 25
3.2.4.4. Border Gateway Protocol . . . . . . . . . . . . . 25
3.2.4.5. Dynamic MANET On-Demand (DYMO) Routing . . . . . . 25
3.2.4.6. Optimized Link State Routing Protocol . . . . . . 26
3.2.4.7. Routing for Low-Power and Lossy Networks . . . . . 26
3.2.5. IPv6 Multicast Forwarding and Routing . . . . . . . . 27
3.2.5.1. Protocol-Independent Multicast Routing . . . . . . 27
3.2.6. Adaptation to Lower-Layer Networks and Link Layer
Protocols . . . . . . . . . . . . . . . . . . . . . . 28
3.3. Transport Layer . . . . . . . . . . . . . . . . . . . . . 28
3.3.1. User Datagram Protocol (UDP) . . . . . . . . . . . . . 28
3.3.2. Transmission Control Protocol (TCP) . . . . . . . . . 29
3.3.3. Stream Control Transmission Protocol (SCTP) . . . . . 29
3.3.4. Datagram Congestion Control Protocol (DCCP) . . . . . 30
3.4. Infrastructure . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1. Domain Name System . . . . . . . . . . . . . . . . . . 30
3.4.2. Dynamic Host Configuration . . . . . . . . . . . . . . 31
3.4.3. Network Time . . . . . . . . . . . . . . . . . . . . . 31
3.5. Network Management . . . . . . . . . . . . . . . . . . . . 31
3.5.1. Simple Network Management Protocol (SNMP) . . . . . . 31
3.5.2. Network Configuration (NETCONF) Protocol . . . . . . . 32
3.6. Service and Resource Discovery . . . . . . . . . . . . . . 33
3.6.1. Service Discovery . . . . . . . . . . . . . . . . . . 33
3.6.2. Resource Discovery . . . . . . . . . . . . . . . . . . 33
3.7. Other Applications . . . . . . . . . . . . . . . . . . . . 34
3.7.1. Session Initiation Protocol . . . . . . . . . . . . . 34
3.7.2. Extensible Messaging and Presence Protocol . . . . . . 35
3.7.3. Calendaring . . . . . . . . . . . . . . . . . . . . . 35
4. A Simplified View of the Business Architecture . . . . . . . . 35
5. Security Considerations . . . . . . . . . . . . . . . . . . . 40
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40
7.1. Normative References . . . . . . . . . . . . . . . . . . . 40
7.2. Informative References . . . . . . . . . . . . . . . . . . 41
Appendix A. Example: Advanced Metering Infrastructure . . . . . . 58
A.1. How to Structure a Network . . . . . . . . . . . . . . . . 59
A.1.1. HAN Routing . . . . . . . . . . . . . . . . . . . . . 62
A.1.2. HAN Security . . . . . . . . . . . . . . . . . . . . . 62
A.2. Model 1: AMI with Separated Domains . . . . . . . . . . . 64
A.3. Model 2: AMI with Neighborhood Access to the Home . . . . 65
A.4. Model 3: Collector Is an IP Router . . . . . . . . . . . . 66This is part 1 of 14, so the good stuff is still coming 🌈💅 Part 2 starts with Section 1, Introduction, so stay tuned, bestie 🫶✨
1. Introduction ✨
Okay bestie, this doc is literally giving Smart Grid designers advice on how to "profile" the Internet Protocol Suite (IPS) so it works for Smart Grids 🔌💖. It gives you an overview of the IPS and the key infrastructure protocols that matter most when you're plugging Smart Grid devices into an IP-based infrastructure ✨.
Wikipedia [SmartGrid] explains it so well, so here's my remix of that description 💅:
A Smart Grid is an electricity network that runs on digital tech. It delivers power from suppliers to consumers using two-way digital communications to control the appliances in people's homes, which saves energy, cuts costs, and boosts reliability and transparency. It sits on top of the ordinary electrical grid with an information and net metering system that includes smart meters. Governments are super into it as a way to tackle energy independence, global warming, and emergency resilience 🌍.
A Smart Grid is made possible by putting sensing, measurement, and control devices with two-way communications into the parts of the power grid that handle production, transmission, distribution, and consumption. Those devices share info about what's going on in the grid with users, operators, and automated devices, so the whole system can respond dynamically to changes in grid condition 🔄.
A Smart Grid also has an intelligent monitoring system that tracks all the electricity flowing through it, and it can bring in renewables like solar and wind ☀️🌬️. When power is cheapest, the user can let the Smart Grid switch on things like washing machines or factory processes that can run at any hour. At peak times, it could switch off certain appliances to cut demand 🧺.
People also call a Smart Grid (or similar proposals) a smart electric or power grid, an intelligent grid (or intelliGrid), a futureGrid, or the more modern interGrid and intraGrid 🧚.
That description is mostly about what Smart Grids mean for a consumer at home. But data communications technologies of all kinds are used throughout the Grid to monitor and maintain power generation, transmission, and distribution, and to run the operations and management of the Grid too. You can think of the Smart Grid as a bunch of interconnected computer networks that link and serve public and private electrical utilities and their customers 🫶.
Here's the tea: right now there's no single document that counts as an internationally agreed standard for the Smart Grid. Sorting that out is literally part of the work going on in its development 😭. The closest things are probably the Smart Grid Interoperability Panel's Conceptual Model [Model] and the documents that make up [IEC61850] 🦋.
The IPS offers choices for lots of architectural components. For example, it has several options for the traditional transport function between two systems: the Transmission Control Protocol (TCP) [RFC0793], the Stream Control Transmission Protocol (SCTP) [RFC4960], and the Datagram Congestion Control Protocol (DCCP) [RFC4340]. Another option is to pick an encapsulation like the User Datagram Protocol (UDP) [RFC0768], which basically lets an application build its own transport service 🛠️. In practice, a designer picks the transport protocol that fits the problem being solved, periodt 💯.
The IPS is standardized by the Internet Engineering Task Force (IETF), and IETF protocols are documented in the Request for Comments (RFC) series 📜. Several RFCs describe how the IPS should be implemented. These include:
- Requirements for Internet Hosts - Communication Layers [RFC1122],
- Requirements for Internet Hosts - Application and Support [RFC1123],
- Requirements for IP Version 4 Routers [RFC1812], and
- IPv6 Node Requirements [RFC4294].
Also, RFC 4294 is being updated right now, in [IPv6-NODE-REQ] 👀.
This document is meant to give Smart Grid architects and designers a compendium of relevant RFCs (and, to some extent, Internet Drafts). It's organized as an annotated list of RFCs 🎀. So here's how the rest of it is laid out:
- Section 2 describes the Internet Architecture and its protocol suite.
- Section 3 outlines a set of protocols that may be useful in Smart Grid deployment. It is not exhaustive.
- Finally, Section 4 gives an overview of the business architecture embodied in the design and deployment of the IPS.
2. The Internet Protocol Suite 🌸
Before we list the Internet protocols that matter for Smart Grid, we need to talk about the layered architecture of the IPS, what each layer does, and the protocols that go with them 🧠.
2.1. Internet Protocol Layers
Internet architecture uses definitions and language that are pretty similar to the ISO Open System Interconnect (ISO-OSI) reference model (Figure 1), but honestly, it came first 🙈. So the terminology is a little bit skewed. For example, the ISO-OSI model says "end system" where the Internet architecture says "host". And an "intermediate system" in ISO-OSI is called an "internet gateway" or "router" in Internet-speak. Even with those differences, the core concepts are mostly the same 💜.
+--------------------+
| Application Layer |
+--------------------+
| Presentation Layer |
+--------------------+
| Session Layer |
+--------------------+
| Transport Layer |
+--------------------+
| Network Layer |
+--------------------+
| Data Link Layer |
+--------------------+
| Physical Layer |
+--------------------+
Figure 1: The ISO OSI Reference ModelThe Internet reference model is shown in Figure 2 🦋.
+---------------------------------+
|Application |
| +---------------------------+ |
| | Application Protocol | |
| +----------+----------------+ |
| | Encoding | Session Control| |
| +----------+----------------+ |
+---------------------------------+
|Transport |
| +---------------------------+ |
| | Transport Layer | |
| +---------------------------+ |
+---------------------------------+
|Network |
| +---------------------------+ |
| | Internet Protocol | |
| +---------------------------+ |
| | Lower Network Layers | |
| +---------------------------+ |
+---------------------------------+
|Media Layers |
| +---------------------------+ |
| | Data Link Layer | |
| +---------------------------+ |
| | Physical Layer | |
| +---------------------------+ |
+---------------------------------+
Figure 2: The Internet Reference Model2.1.1. Application
In the Internet model, the Application, Presentation, and Session layers get squished into one thing called "the application" 🎀. For example, the Simple Network Management Protocol (SNMP) [RFC3411] is an application that encodes its data in an ASN.1 profile and runs a session to manage a network element. The point is that the Internet does have those layers, it just doesn't call them out 🤫. Also, in Figure 2, these functions aren't necessarily neatly layered. The fact that an application protocol encodes its data one way and manages sessions another way doesn't mean there's a hierarchy between those processes. Instead, the application sees encoding, session management, and a bunch of other services as a toolset it uses while it does its job 🧰.
2.1.2. Transport
"Transport" is honestly one of the most confusing words in communication architecture 😵💫. That's mostly because people from different backgrounds use it to mean "the layer below the one I care about, which gets my data to my peer." For example, optical network engineers call optical fiber and its electronics "the transport," while web designers call the Hypertext Transfer Protocol (HTTP) [RFC2616] (an application layer protocol) "the transport" 🙃.
In the Internet protocol stack, "transport" is the lowest protocol layer that travels end-to-end unmodified, and it's responsible for end-to-end data delivery services. On the Internet, the transport layer sits above the network layer. Transport layer protocols have one minimum requirement: they have to be able to multiplex several applications on one IP address 🔀. UDP [RFC0768], TCP [RFC0793], DCCP [RFC4340], SCTP [RFC4960], and NORM [RFC5740] each do this with a pair of port numbers, one for the sender and one for the receiver. A port number identifies an application instance, which might be a general "listener" that peers or clients can open sessions with, or a specific correspondent with such a "listener" 🎧. The session identification in an IP datagram is often called the "five-tuple." It consists of the source and destination IP addresses, the source and destination ports, and an identifier for the transport protocol in use 🔑.
On top of that, a specific transport layer protocol's responsibilities usually include delivering data (either as a stream of messages or a stream of bytes) in a stated sequence, with stated expectations about delivery rate and loss 📦. For example, TCP lowers its rate in response to loss, as a congestion control trigger, while DCCP accepts some level of loss when it's necessary to keep things timely ⏱️.
2.1.3. Network
The main job of the network layer is to identify a remote destination and deliver data to it 📍. In connection-oriented networks like Multi-protocol Label Switching (MPLS) [RFC3031] or Asynchronous Transfer Mode (ATM), a path gets set up once and data is delivered through it 🛤️. In connectionless networks like Ethernet and IP, data gets delivered as datagrams. Each datagram carries both the source and destination network layer addresses, and the network is responsible for delivering it 📬. In the Internet Protocol Suite, the Internet Protocol is the network layer that runs end to end 🌈. It can be encapsulated over other LAN and WAN technologies, including both IP networks and networks of other types ✨.
2.1.3.1. Internet Protocol
okay so IPv4 and IPv6 are both called the Internet Protocol, and they're both connectionless ("datagram") architectures 📦✨ bestie, they're built as common elements that connect network elements across a whole bunch of lower-layer networks 🌸 on top of the basic job of figuring out a datagram's source and destination, they also fragment and reassemble datagrams when needed, help with diagnosing network failures, and carry extra info for special cases 🔥
The Internet layer gives you a uniform network abstraction that hides the differences between all the network technologies underneath 🦋 this is the layer that lets totally different networks like Ethernet, 802.15.4, etc. get blended into one uniform IP network, and it's giving unified 💜 new network technologies can join the IP Protocol Suite just by defining how IP is carried over them, and the other layers of the IPS and the applications that use those protocols stay unchanged ✨
2.1.3.2. Lower-Layer Networks
the network layer can be recursively subdivided as needed 🧚 one way to do that is tunneling, where an IP datagram gets encapsulated in another IP header so it can be delivered to a decapsulator 💅 IP is frequently carried in Virtual Private Networks (VPNs) across the public Internet using tunneling tech like the Tunnel mode of IPsec, IP-in-IP, and Generic Route Encapsulation (GRE) [RFC2784] 🎀 it also gets carried in circuit networks like MPLS [RFC4364], GMPLS, and ATM 🌈 and finally, IP is carried over wireless networks (IEEE 802.11, 802.15.4, or 802.16) and switched Ethernet (IEEE 802.3) networks 🫶
2.1.4. Media Layers: Physical and Link
at the lowest layer of the IP architecture, data gets encoded into messages and transmitted over the physical media 🍓 the IETF specifies algorithms for carrying IPv4 and IPv6 over various media types, but it rarely actually defines the media itself 💀 it happily borrows specifications from IEEE, ITU, and other sources instead 😭
2.2. Security Issues
ngl, complaining about Internet security is super popular, but it's important to tell apart attacks on protocols and attacks on users (e.g., phishing) 🙈 attacks on users are mostly independent of protocol details, come from interface design issues or user education problems, and are out of scope for this document 🌸 security problems with Internet protocols are totally in scope though, and they can often be mitigated using existing security features already specified for the protocol, or by leaning on the security services offered by other IETF protocols 💖 for more on TCP and IPv4 issues, check out the Security Assessment of the Transmission Control Protocol (TCP) [TCP-SEC] and the Security Assessment of the Internet Protocol version 4 [IP-SEC] 🔥
these solutions do, however, need to get deployed too! 😭 the road to widespread deployment can be painful since often multiple stakeholders have to take actions 💅 experience has shown that this takes some time, and it very often only happens when the incentives are high enough compared to the costs 💸
also, it's important to stress that available standards matter, but the range of security problems is bigger than just a missing standard 🫠 lots of security problems come from implementation bugs and certain deployment choices 🙈 those are outside the realm of standards development, but they play a big role in the security of the overall system ✨ security has to be integrated into the entire process, bestie 👑
the IETF takes security seriously in the design of its protocols and architectures 🦋 every IETF specification has to have a Security Considerations section to document the offered security threats and countermeasures 🎀 RFC 3552 [RFC3552] gives recommendations on writing that section, and it also describes the classical Internet security threat model and lists common security goals 💜
in a nutshell, security has to be built into every protocol, protocol extension, and therefore every layer of the protocol stack to actually be useful 🧚 we'll keep illustrating this throughout the document with references to further security discussions 🌈 our experience has shown that treating security as an afterthought does not lead to the desired outcome 💀
the discussion of security threats and available security mechanisms is meant to illustrate some of the design aspects that commonly show up 🍓
2.2.1. Physical and Data Link Layer Security
at the physical and data link layers, threats mostly center on physical attacks on the network 🚧 we're talking backhoes, deteriorating physical media, and all kinds of environmental noise 😭 radio-based networks are subject to signal fade due to distance, interference, and environmental factors 📡 it's widely noted that IEEE 802.15.4 networks often place a metal ground plate between the meter and the device that manages it 🙈 fiber was once deployed because people believed it was untappable, but we've since learned to tap it by bending the fiber and collecting incidental light, and we've learned about backhoes too 💀 as a result, some installations encase fiber optic cable in a pressurized sheath, both to quickly identify the location of a cut and to make it harder to tap 🔥
while there are protocol behaviors that can detect certain classes of physical faults, like keep-alive exchanges, physical security is generally not considered to be a protocol problem 💅
for wireless transmission technologies, eavesdropping on transmitted frames is also typically a concern 👀 on top of that, those operating networks may want to make sure access to their infrastructure is restricted to those who are authenticated and authorized (typically called 'network access authentication') 🫶 this procedure is often offered by security primitives at the data link layer 🌸
2.2.2. Network, Transport, and Application Layer Security
at the network, transport, and application layers, it's common to demand a few basic security requirements, commonly referred to as CIA (Confidentiality, Integrity, and Availability) 💖
- Confidentiality: protect the transmitted data from unauthorized disclosure (i.e., keep eavesdroppers from learning what was transmitted) 🔒 for example, for trust in e-commerce applications, credit card transactions are exchanged encrypted between the Web browser and a Web server 💳
- Integrity: protect against unauthorized changes to exchanges, including both intentional change or destruction and accidental change or loss, by making sure changes to exchanges are detectable 🔍 it has two parts, one for the data and one for the peers 👯
- peers need to verify that information that appears to be from a trusted peer really is from that peer 🫶 this is typically called 'data origin authentication' ✨
- peers need to validate that the content of the data exchanged is unmodified 💅 the term typically used for this property is 'data integrity' 💜
- Availability: ensure that the resource is accessible by mitigating denial-of-service attacks 🛡️
to this we add authenticity, which requires that the communicating peers prove they are actually who they say they are to each other (i.e., mutual authentication) 🪪 this generally means knowing "who" the peer is, and that they demonstrate possession of a "secret" as part of the security protocol interaction 🤫
the following three examples are here to illustrate these security requirements 🌈
one common attack against a TCP session is to bombard the session with reset messages 😤 other attacks against TCP include the "SYN flooding" attack, where an attacker tries to exhaust the memory of the target by creating TCP state 💀 specifically, the attacker tries to exhaust the target's memory by opening a large number of unique TCP connections, each represented by a Transmission Control Block (TCB) 🧠 the attack works if the attacker can make the target fill its memory with TCBs 😱
a number of mechanisms have been developed to deal with these types of denial-of-service attacks 🦋 one, "SYN Cookies", delays state establishment on the server side until a later phase in the protocol exchange ⏳ another mechanism, specifically targeting the reset attack mentioned above, provides authentication services in TCP itself so that fake resets get rejected 🙅♀️
another approach would be to offer security protection already at a lower layer, like IPsec (see Section 3.1.2) or TLS (see Section 3.1.3), so a host can identify legitimate messages and discard the others, which mitigates any damage the attack may have caused 🛡️✨
another common attack involves unauthorized access to resources 🚪 for example, an unauthorized party might try to attach to a network 🥷 to protect against this, an Internet Service Provider (ISP) typically requires network access authentication of new hosts demanding access to the network and the Internet before offering access 🎟️ this exchange typically requires authentication of that entity and a check in the ISPs back-end database to see whether corresponding subscriber records exist and are still valid (e.g., active subscription and sufficient credits) 💳
from the discussion above, establishing a secure communication channel is clearly an important concept that's frequently used to mitigate a range of attacks 🔐 unfortunately, focusing only on channel security may not be enough for a given task 😬 threat models have evolved, and even some of the communication endpoints can't be considered fully trustworthy, i.e., even trusted peers may act maliciously 👀
furthermore, many protocols are more sophisticated in their interaction and involve more than two parties in the exchange 🧩 lots of application layer protocols, like email, instant messaging, voice over IP, and presence-based applications, fall into this category 📱 with this class of protocols, secure data (such as DNS records) and secure communications with middleware, intermediate servers, and supporting applications need to be considered as well as the security of the direct communication 🌸 a detailed treatment of the security threats and requirements of these multi-party protocols is beyond this specification, but the interested reader is referred to the examples above for an illustration of what technical mechanisms have been investigated and proposed in the past 📚
2.3. Network Infrastructure
while the following protocols aren't critical to the design of a specific system, they're important for running a network, so we survey them here 🧚
2.3.1. Domain Name System (DNS)
the DNS' main function is translating names to numeric IP addresses 🗺️ while this isn't critical to running a network, certain functions get a lot easier if numeric addresses can be replaced with mnemonic names 💖 this facilitates renumbering of networks and generally improves the manageability and serviceability of the network 🫶 DNS has a set of security extensions called DNSSEC, which can be used to provide strong cryptographic authentication to the DNS 🔐 DNS and DNSSEC are discussed further in Section 3.4.1 👑
2.3.2. Network Management 🛠️
Okay so network management has been a genuinely hard problem, bestie 😭 That's why people have tried a bunch of different solutions over the years, and every one of them has fans with really solid arguments. For device operation, the IETF has two big options. SNMP is ASN.1-encoded and mostly used for keeping an eye on system variables 👀. NETCONF [RFC4741] is XML-encoded and mostly used for configuring devices ⚙️.
Another part of network management is the first-time provisioning and configuration of hosts, which we cover in Section 3.4.2 🎀. Here's the tea: Smart Grid deployments may need identity authentication and authorization (plus other provisioning and configuration stuff) that might not fit inside DHCP or Neighbor Discovery 🙈. The IP Protocol Suite does have limited support for secure provisioning and configuration, but these problems have already been solved with IP protocols in specs like DOCSIS 3.0 [SP-MULPIv3.0] ✨.
3. Specific Protocols 💅
In this section, we've already walked through the basics of the IP architecture and some of the problems it's trying to fix 🦋. Now we get to introduce specific protocols that could fit different Smart Grid use cases 🔥. Use cases should be analyzed alongside privacy, Authentication, Authorization, and Accounting (AAA), transport, and network solution dimensions. The next sections give you guidance for doing that analysis 🧚.
3.1. Security Toolbox 🧰
As we already mentioned, a big deal in security solutions is doing a solid threat analysis and pairing it with good mitigation strategies at each layer 🔐. Over time, the IETF has built up a bunch of security building blocks, based on the observation that protocols often need similar security services 💜. The sub-sections below cover a few of the ones people use all the time. Reusing them is iconic for a few reasons: there's open source code available, there's experience with existing systems, there are lots of extensions already made, and the listed technologies have been reviewed and analyzed by plenty of security experts 🫶.
Also, every protocol usually comes with its own extra security considerations that are specific to the domain it runs in 🙈. Lots of protocols include features designed specifically to reduce those protocol-specific risks 🛡️. In other cases, the security considerations will call out security-relevant services that are required from other network layers to reach appropriate levels of security 🌈.
3.1.1. Authentication, Authorization, and Accounting (AAA) 🗝️
Okay, AAA sounds super generic, like it could apply to any security protocol 💀. But in the IETF it's been used specifically for network access authentication, and it's tied to RADIUS ([RFC2865]) and the Diameter protocol ([RFC3588], [DIME-BASE]) in particular 🍓.
The authentication procedure for network access is about verifying that a peer is authenticated and authorized before it can get at a particular resource (usually connectivity to the Internet) 🌸. Typically, the authentication architecture for network access is made of these building blocks: the Extensible Authentication Protocol (EAP [RFC4017]) as a container for EAP methods, an EAP Method (a specific way to do cryptographic authentication and key exchange, such as the ones described in RFC 5216 [RFC5216] and RFC 5433 [RFC5433]), a protocol that carries EAP payloads between the end host and a server-side entity (like a network access server), and a way to carry EAP payloads to back-end server infrastructure (possibly in a cross-domain scenario) to provide authorization and accounting. That last part is handled by RADIUS and Diameter 💖. To carry EAP payloads between the end host and a network access server, different mechanisms have been standardized, like the Protocol for Carrying Authentication for Network Access (PANA) [RFC5191] and IEEE 802.1X [IEEE802.1X]. For access to remote networks, such as enterprise networks, it's also possible to use EAP within IKEv2 [RFC5996] 🔑.
More recently, that same architecture, with EAP and RADIUS/Diameter, is being reused for application layer protocols 🌟. You can find more details about this architectural variant in [ABFAB-ARCH] ✨.
3.1.2. Network Layer Security 🌐
IP security, described in [RFC4301], handles security at the IP layer using a combo of cryptographic and protocol security mechanisms 🔒. It offers a set of security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. That set includes access control, connectionless integrity, data origin authentication, detection and rejection of replays (a form of partial sequence integrity), confidentiality (via encryption), and limited traffic-flow confidentiality 💅. These services are provided at the IP layer, so they protect, in a standard way, all the protocols that may be carried over IP (including IP itself) 🦋.
The architecture splits things into two parts: (a) an authentication and key exchange step that's kind of time-consuming and also sets up a security association (a data structure with keying material and security parameters), and (b) the actual protection of the data traffic 🧁.
For the first step, the Internet Key Exchange protocol version 2 (IKEv2 [RFC5996]) is the most recent edition of the standardized protocol 🗝️. IKE negotiates each cryptographic algorithm that will be used to protect the data independently, kind of like picking items a la carte 🍽️.
For the actual data protection, two types of protocols have historically been used: the IP Authentication Header (AH) [RFC4302] and the Encapsulating Security Payload (ESP) [RFC4303]. They differ in the security services they offer, and the biggest difference is that ESP offers confidentiality protection while AH does not 👀. Since ESP can also provide authentication services, the most recent protocol developments that use IPsec only specify ESP and don't use AH 🙌.
On top of these base line protocol mechanisms, a bunch of extensions have been developed for IKEv2 (for example, an extension to do EAP-only authentication [RFC5998]). And since the architecture supports flexible treatment of cryptographic algorithms, a number of them have been specified too (for example, [RFC4307] for IKEv2, and [RFC4835] for AH and ESP) 🌈.
3.1.3. Transport Layer Security 🔐
Transport Layer Security v1.2 [RFC5246] is a set of security services that protect data above the transport layer 💖. It lets client/server applications talk to each other in a way that's designed to prevent eavesdropping, tampering, or message forgery 🛡️. TLS is application protocol independent, so it doesn't care what app is on top 🦋.
TLS is made of two layers: the TLS Record protocol and the TLS Handshake protocol 🧩. The TLS Record protocol gives you connection security with two basic properties: (a) confidentiality protection and (b) integrity protection 🔒.
The TLS Handshake protocol lets the server and client authenticate each other and negotiate an encryption algorithm and cryptographic keys before the application protocol sends or receives its first byte of data 🤝. The negotiated parameters and the derived keying material are then used by the TLS Record protocol to do its job ✨.
Unlike IKEv2/IPsec, TLS negotiates these cryptographic parameters in suites, so-called 'cipher suites' 🎀. Examples of cipher suites that can be negotiated with TLS include Elliptic Curve Cryptography (ECC) [RFC4492] [RFC5289] [AES-CCM-ECC], Camellia [RFC5932], and the Suite B Profile [RFC5430]. [IEC62351-3] outlines the use of different TLS cipher suites for the Smart Grid ⚡. The basic cryptographic mechanisms for ECC have been documented in [RFC6090] 📚.
TLS must run over a reliable transport channel, typically TCP 🚂. To offer the same security services for unreliable datagram traffic, like UDP, the Datagram Transport Layer Security (DTLS [RFC4347] [DTLS]) was developed 🦋.
3.1.4. Application Layer Security 📱
Sometimes the application layer independent security mechanisms from the previous sub-sections just aren't enough to deal with all the threats that have been identified 😤. For that, there are a bunch of security primitives available at the application layer, where the semantics of the application can be taken into account 🧠.
We're going to focus on a few mechanisms that are commonly used across the Internet 🌍.
Cryptographic Message Syntax (CMS [RFC5652]) is an encapsulation syntax for signing, digesting, authenticating, or encrypting arbitrary message content 💌. It also lets you sign arbitrary attributes, like signing time, along with the message content, and it provides other attributes, such as countersignatures, to be associated with a signature 🖊️. CMS can support a variety of architectures for certificate-based key management, like the one defined by the PKIX (Public Key Infrastructure using X.509) working group [RFC5280] 🎀. CMS has been used to supply security services in a variety of protocols, including secure email [RFC5751], key management [RFC5958] [RFC6031], and firmware updates [RFC4108] 🌸.
Related work includes using digital signatures on XML-encoded documents, which W3C and the IETF jointly standardized [RFC3275] 🧡. Digitally signed XML is a great choice where applications natively support XML-encoded data, like the Extensible Messaging and Presence Protocol (XMPP) 💬.
More recently, delegated authentication and authorization, which Web applications often need, have been handled with the Open Web Authentication (OAuth) protocol [RFC5849] [OAUTHv2] 🌐. OAuth lets third-party applications access protected resources (like energy consumption info about a specific household) without the resource owner having to share its long-term credentials with that third party 🏠. In OAuth, the third-party application asks for access to resources controlled by the resource owner and hosted by the resource server, and it gets issued a different set of credentials than the resource owner's 🗝️. Specifically, third-party applications get an access token during the OAuth protocol exchange. That token denotes a specific scope, duration, and other access attributes 🎟️. So the app can securely reach the protected resource, with the resource owner's consent 🫶.
3.1.5. Secure Shell 🐚
The Secure Shell (SSH) protocol [RFC4253] has been widely used by admins and others for secure remote login, and it can also be used for secure tunneling 💻. More recently, protocols have started layering on top of SSH for transport security services. For example, the NETCONF network management protocol (see Section 3.5.2) uses SSH as its main communications security protocol 🌈✨
3.1.6. Key Management Infrastructures ✨
okay so all of the security protocols we just talked about run on cryptography 🔐, which means they all need some form of key management 🗝️. Most IETF protocols at least nominally require some scalable form of key management to be defined as mandatory to implement, and honestly the lack of those key management features has been a reason to delay approval of protocols before 😭. There are two generic key management schemes that other Internet protocols use all the time, PKIX and Kerberos, and we'll go through each one real quick 💅.
3.1.6.1. PKIX
Public Key Infrastructure (PKI) is the kind of key management based on certification authorities (CAs) issuing public key certificates for other key holders 📜. You start at a trust anchor (a locally trusted copy of a CA public key) and chain all the way down to the public key of some protocol peer 🔗. That lets PKI securely bind keys to protocol-specific names, like email addresses, which means it enables security services such as data and peer authentication, data integrity, and confidentiality (encryption) 🔒✨.
The main Internet standard for PKI is [RFC5280], which is a profile of the X.509 public key certificate format 🎀. There are a bunch of private and commercial CAs operating today that can manage and securely distribute keys for every protocol that uses public key certificates, like TLS and S/MIME 💜. On top of the profile standard, the PKIX working group has defined a number of management protocols (e.g., [RFC5272] and [RFC4210]) 🧚, plus protocols for handling revocation of public key certificates, such as the Online Certificate Status Protocol (OCSP) [RFC2560] 🙈.
PKI is generally seen as better at handling use cases that span multiple independent domains compared to Kerberos 🌈.
3.1.6.2. Kerberos
The Kerberos Network Authentication System [RFC4120] is commonly used inside organizations to centralize authentication, authorization, and policy in one place 🏢👑. Kerberos natively supports usernames and passwords as the basis of authentication 🔑. With Public Key Cryptography for Initial Authentication in Kerberos (PKINIT) [RFC4556], Kerberos also supports certificate or public-key-based authentication 🎟️. This may be an advantage, since it concentrates policy about certificate validation and the mapping of certificates to user accounts in one place 🫶. Through the GSS-API [RFC1964] [RFC2743] [RFC4121], Kerberos can manage authentication for most applications 🍓. Kerberos works best within organizations and enterprises, but it does have facilities that let authentication be shared between administrative domains 🦋.
3.2. Network Layer
okay the IPS specifies two network layer protocols: IPv4 and IPv6 🌸. The following sections describe the IETF's coexistence and transition mechanisms for IPv4 and IPv6 💖.
Note that on 3 February 2011, the IANA's IPv4 free pool (the pool of available, unallocated IPv4 addresses) ran out 😭. The Regional Internet Registrars' (RIRs') free pools are expected to be exhausted during the coming year, if not sooner 💀. The IETF, the IANA, and the RIRs recommend that new deployments use IPv6, and that IPv4 infrastructures be supported via the mechanisms described in Section 3.2.1 🫶🔥.
3.2.1. IPv4/IPv6 Coexistence Advice
The IETF has specified a variety of mechanisms designed to help IPv4 and IPv6 coexist 🦋. It actually recommends relatively few of them 🙈. The current advice to network operators is in Guidelines for Using IPv6 Transition Mechanisms [RFC6180], and the thoughts in that document are repeated here 🎀.
3.2.1.1. Dual Stack Coexistence
The simplest coexistence approach is to:
- provide a network that routes both IPv4 and IPv6,
- ensure that servers and their applications similarly support both protocols, and
- require that all new systems and applications purchased or upgraded support both protocols.
The net result is that over time all systems become protocol agnostic, and eventually maintaining IPv4 support becomes a business decision 💅✨. This approach is described in Basic Transition Mechanisms for IPv6 Hosts and Routers [RFC4213] 🧚.
3.2.1.2. Tunneling Mechanism
In those places in the network that support only IPv4, the simplest and most reliable approach to coexistence is to provide virtual connectivity using tunnels or encapsulations 🚇. Early in IPv6 deployment, this was often done with static tunnels 🌈. A more dynamic approach is documented in IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5569] 🍓.
3.2.1.3. Translation between IPv4 and IPv6 Networks
In cases where an IPv4-only host wants to talk to an IPv6-only host (or the other way around), protocol translation may be needed 🤔. At first blush it seems trivial, but on deeper inspection, protocol translation can get really complicated 😭🫠.
The most reliable approach to protocol translation is to provide application layer proxies or gateways 💖. They natively enable application-to-application connections using both protocols, and they can use whichever one is appropriate 🫶. For example, a web proxy might use both protocols, so an IPv4-only system can run HTTP across an IPv6-only network, or reach a web server that only implements IPv6 🌸. Since this approach is a service of a protocol-agnostic server, it isn't something the IETF standardizes 🙈.
For applications where network layer translation is indicated, the IETF has designed a translation mechanism, described in the following documents:
- Framework for IPv4/IPv6 Translation [RFC6144]
- IPv6 Addressing of IPv4/IPv6 Translators [RFC6052]
- DNS extensions [RFC6147]
- IP/ICMP Translation Algorithm [RFC6145]
- Translation from IPv6 Clients to IPv4 Servers [RFC6146]
As with IPv4/IPv4 Network Address Translation, translation between IPv4 and IPv6 has limited real world applicability for an application protocol that carries IP addresses in its payload and expects those addresses to be meaningful to both client and server 🙃. For protocols that don't do that, though, protocol translation can be a super useful network extension 👑.
Network-based translation provides two types of services 💅. The first is stateless translation (scalable and load-sharable) between IPv4 and IPv6 addresses that embed an IPv4 address in them 🧚. The second is stateful translation, similar to IPv4/IPv4 translation between IPv4 addresses 🍓. The stateless mode is straightforward to implement, but because of the embedding, it requires IPv4 addresses to be allocated to an otherwise IPv6-only network, and it's mainly useful for IPv4-accessible servers implemented in the IPv6 network 🌈. The stateful mode lets clients in the IPv6 network access servers in the IPv4 network, but it doesn't provide that service for IPv4 clients accessing IPv6 peers or servers with general addresses 🫠. Its advantage is that it doesn't require a unique IPv4 address to be embedded in the IPv6 address of hosts using this mechanism 💖.
Finally, some site networks are IPv6 only while some transit networks are IPv4 only 🚦. In these cases, it may be necessary to tunnel IPv6 over IPv4 or translate between IPv6 and IPv4 🔁✨.
3.2.2. Internet Protocol Version 4
IPv4 [RFC0791] and the Internet Control Message Protocol (ICMP) [RFC0792] make up the IPv4 network layer 🌸. IPv4 provides unreliable delivery of datagrams 🙈.
IPv4 also provides fragmentation and reassembly of long datagrams, so they can travel through networks with small Maximum Transmission Units (MTU) 🧩. The MTU is the largest packet size that can be delivered across the network 📦. The IPS also provides ICMP [RFC0792], a separate protocol that lets the network report errors and other issues to the hosts that originate problematic datagrams 🚨.
IPv4 originally supported an experimental type of service field that identified eight levels of operational precedence, styled after the requirements of military telephony 📞. It also had three, and later four, bit flags that OSI IS-IS for IPv4 (IS-IS) [RFC1195] and OSPF Version 2 [RFC2328] interpreted as control traffic 🎛️. That control traffic is assured of not being dropped when queued or upon receipt, even if other traffic is being dropped 🛡️. These control bits turned out to be less useful than the designers had hoped 😭. They were replaced by the Differentiated Services Architecture [RFC2474] [RFC2475], which contains a six-bit code point used to select an algorithm (a "per-hop behavior") to apply to the datagram 🦋. The IETF has also produced a set of Configuration Guidelines for DiffServ Service Classes [RFC4594], which describes a set of service classes that may be useful to a network operator 💅.
3.2.2.1. IPv4 Address Allocation and Assignment
IPv4 addresses are administratively assigned, usually with automated methods, using the Dynamic Host Configuration Protocol (DHCP) [RFC2131] 🤖. On most interface types, neighboring systems identify each other's addresses using the Address Resolution Protocol (ARP) [RFC0826] 🫶.
3.2.2.2. IPv4 Unicast Routing
Routing for the IPv4 Internet is done by routing applications that exchange connectivity information and build semi-static destination routing databases 🗺️. If a datagram is directed to a given destination address, that address is looked up in the routing database, and the most specific ("longest") prefix found that contains it is used to identify the next-hop router or the end system it will be delivered to 🎯. This isn't generally implemented on hosts, although it can be 🙃. A host normally sends datagrams to a router on its local network, and the router carries out the intent 👑.
IETF specified routing protocols include RIP Version 2 [RFC2453], OSI IS-IS for IPv4 [RFC1195], OSPF Version 2 [RFC2328], and BGP-4 [RFC4271] 🌈. There's active research in mobile ad hoc routing and other routing paradigms, and those are resulting in new protocols and modified forwarding paradigms 🧪✨.
3.2.2.3. IPv4 Multicast Forwarding and Routing ✨
okay bestie, so IPv4 was originally built as a unicast (point to point) protocol 💅 and then it got a multicast glow-up in [RFC1112]. 🦋 It uses the Internet Group Management Protocol [RFC3376] [RFC4604] so apps can join multicast groups, and for most apps it uses Source-Specific Multicast [RFC4607] for routing and delivery of multicast messages. 🫶
Then there's this experiment in IPv4 that isn't part of the core Internet architecture but might be interesting for the Smart Grid 🔌: "Reliable Multicast." The "so-called" is doing a lot of work here, because it's not "reliable" in the strict sense of the word. It's more like "enhanced reliability" 🙈 A best effort network by definition can lose traffic, duplicate it, or reorder it, and that's just as true for multicast as it is for unicast 😭 So research in "Reliable Multicast" tech is trying to improve the probability of delivery of multicast traffic. ✨
In that research, the IETF put out guidelines [RFC2357] for the research community about what was desirable 📝 Important results include a bunch of papers and several proprietary protocols, some of which have been used to support business operations. RFCs in this area include The Use of Forward Error Correction (FEC) in Reliable Multicast [RFC3453], the Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Protocol [RFC5740], and the Selectively Reliable Multicast Protocol (SRMP) [RFC4410]. 🎀
3.2.3. Internet Protocol Version 6 🌈
IPv6 [RFC2460], together with the Internet Control Message Protocol "v6" [RFC4443], is the next generation protocol for the Internet 👑 IPv6 handles sending datagrams from source to destination hosts, which are identified by fixed-length addresses.
IPv6 also handles fragmentation and reassembly of long datagrams by the originating host, if necessary, for transmission through "small packet" networks 🧚 ICMPv6 is a separate protocol that's implemented along with IPv6, and it lets the network report errors and other issues to the hosts that originate problematic datagrams. 🚨
IPv6 adopted the Differentiated Services Architecture [RFC2474] [RFC2475], which contains a six-bit code point used to select an algorithm (a "per-hop behavior") to be applied to the datagram. 🍓
The IPv6 over Low-Power Wireless Personal Area Networks RFC [RFC4919] and the Compression Format for IPv6 Datagrams in 6LoWPAN Networks document [6LOWPAN-HC] cover IPv6 header compression and subnet architecture in at least some sensor networks 🌸 They may be a good fit for the Smart Grid Advanced Metering Infrastructure or other sensor domains. 💜
3.2.3.1. IPv6 Address Allocation and Assignment 🎀
An IPv6 Address [RFC4291] may be administratively assigned using DHCPv6 [RFC3315], which is kind of like how IPv4 addresses get assigned 💖 On top of that, IPv6 addresses can also be autoconfigured. Autoconfiguration enables various models of network management that may be advantageous in different use cases ✨ The autoconfiguration procedures are defined in [RFC4862] and [RFC4941]. IPv6 neighbors identify each other's addresses using Neighbor Discovery (ND) [RFC4861]. SEcure Neighbor Discovery (SEND) [RFC3971] may be used to secure these operations 🔐
3.2.3.2. IPv6 Routing 🛣️
Routing for the IPv6 Internet is accomplished by routing applications that exchange connectivity information and build semi-static destination routing databases 🗺️ If a datagram is directed to a given destination address, the address is looked up in the routing database, and the most specific ("longest") prefix that contains it is used to identify the next-hop router or the end system it will be delivered to. Routing is not generally implemented on hosts (although it can be), so usually a host sends datagrams to a router on its local network, and the router carries out the intent 💅
IETF-specified routing protocols include RIP for IPv6 [RFC2080], IS-IS for IPv6 [RFC5308], OSPF for IPv6 [RFC5340], and BGP-4 for IPv6 [RFC2545]. Active research exists in mobile ad hoc routing, routing in low-power networks (sensors and Smart Grids), and other routing paradigms 🔬 These efforts result in new protocols and modified forwarding paradigms. 🦋
3.2.4. Routing for IPv4 and IPv6 🗺️
3.2.4.1. Routing Information Protocol 📣
The prototypical routing protocol used in the Internet has probably been the Routing Information Protocol [RFC1058] 👑 People who use it today tend to deploy RIPng for IPv6 [RFC2080] and RIP Version 2 [RFC2453]. Briefly, RIP is a distance vector routing protocol that is based on a distributed variant of the widely known Bellman-Ford algorithm. In distance vector routing protocols, each router announces the contents of its route table to neighboring routers, which integrate the results with their route tables and re-announce them to others 📢 It has been characterized as "routing by rumor," and it suffers from many of the ills we find in human gossip 💀 That means it can propagate stale or incorrect information in certain failure scenarios, and it can be unresponsive to changes in topology in some cases. [RFC1058] provides guidance to algorithm designers to mitigate these issues. 🫶
3.2.4.2. Open Shortest Path First 🌊
The Open Shortest Path First (OSPF) routing protocol is one of the more widely used protocols in the Internet 🌐 OSPF is based on Dijkstra's well known Shortest Path First (SPF) algorithm. It is implemented as OSPF Version 2 [RFC2328] for IPv4, OSPF for IPv6 [RFC5340] for IPv6, and the Support of Address Families in OSPFv3 [RFC5838] to enable [RFC5340] routing of both IPv4 and IPv6 ✨
The advantage of any SPF-based protocol (i.e., OSPF and IS-IS) is primarily that every router in the network builds its view of the network from first-hand knowledge, rather than the "gossip" that distance vector protocols propagate 🧠 As such, the topology is quickly and easily changed by simply announcing the change. The disadvantage of SPF-based protocols is that each router must store a first-person statement of the connectivity of each router in the domain 😅
3.2.4.3. ISO Intermediate System to Intermediate System 🧩
The Intermediate System to Intermediate System (IS-IS) routing protocol is one of the more widely used protocols in the Internet 💅 IS-IS is also based on Dijkstra's SPF algorithm. It was originally specified as ISO DP 10589 for the routing of Connectionless Network Service (CLNS), and it was extended for routing in TCP/IP and dual environments [RFC1195], and more recently for routing of IPv6 [RFC5308] 🎀
As with OSPF, the positives of any SPF-based protocol, and specifically IS-IS, are primarily that the network is described as a lattice of routers with connectivity to subnets and isolated hosts 🕸️ Its topology is quickly and easily changed by simply announcing the change, without the issues of "routing by rumor," since every host within the routing domain has a first-person statement of the connectivity of each router in the domain. The negatives are a corollary: each router must store a first-person statement of the connectivity of each router in the domain 🥲
3.2.4.4. Border Gateway Protocol 🌉
The Border Gateway Protocol (BGP) [RFC4271] is widely used in the IPv4 Internet to exchange routes between administrative entities (service providers, their peers, their upstream networks, and their customers) while applying specific policy 🤝 Multiprotocol Extensions [RFC4760] to BGP allow BGP to carry IPv6 Inter-Domain Routing [RFC2545], multicast reachability information, and VPN information, among others 🦋
Considerations that apply with BGP deal with the flexibility and complexity of the policies that must be defined. Flexibility is a good thing, but in a network that is not run by professionals, the complexity is burdensome 🙃
3.2.4.5. Dynamic MANET On-Demand (DYMO) Routing 📡
The Mobile Ad Hoc working group of the IETF developed, among other protocols, Ad hoc On-Demand Distance Vector (AODV) Routing [RFC3561] 💜 This protocol captured the minds of some people in the embedded devices industry, but it ran into issues in wireless networks such as 802.15.4 and 802.11's Ad Hoc mode. As a result, it is in the process of being updated in the Dynamic MANET On-demand (DYMO) Routing protocol [DYMO] 🔄
AODV and DYMO are essentially reactive routing protocols designed for mobile ad hoc networks, and they're usable in other forms of ad hoc networks too ⚡ They provide connectivity between a device within a distributed subnet and a few devices (including perhaps a gateway or router to another subnet) without tracking connectivity to other devices. In essence, routing is calculated and discovered upon need, and a host or router only needs to maintain the routes that currently work and are needed 🌷
3.2.4.6. Optimized Link State Routing Protocol 🔗
The Optimized Link State Routing Protocol (OLSR) [RFC3626] is a proactive routing protocol designed for mobile ad hoc networks, and it can be used in other forms of ad hoc networks 🌈 It provides arbitrary connectivity between systems within a distributed subnet. As with protocols designed for wired networks, routing is calculated whenever changes are detected and maintained in each router's tables 🛠️ The set of nodes that operate as routers within the subnet, however, is fairly fluid and dependent on the instantaneous topology of the subnet 🫠
3.2.4.7. Routing for Low-Power and Lossy Networks 🔋
The IPv6 Routing Protocol for Low power and Lossy Networks (RPL) [RPL] is a reactive routing protocol designed for use in resource constrained networks 🪫 Requirements for resource constrained networks are defined in [RFC5548], [RFC5673], [RFC5826], and [RFC5867].
Briefly, a constrained network is made up of nodes that:
- Are built with limited processing power and memory, and sometimes energy when operating on batteries 🔋
- Are interconnected through a low-data-rate network interface and are potentially vulnerable to communication instability and low packet delivery rates 📉
- Potentially have a mix of roles, such as being able to act as a host (i.e., generating traffic) and/or a router (i.e., both forwarding and generating RPL traffic) 🎭
3.2.5. IPv6 Multicast Forwarding and Routing 💌
IPv6 specifies both unicast and multicast datagram exchange 💫 This uses the Multicast Listener Discovery Protocol (MLDv2) [RFC2710] [RFC3590] [RFC3810] [RFC4604] to enable applications to join multicast groups, and for most applications it uses Source-Specific Multicast [RFC4607] for routing and delivery of multicast messages.
The mechanisms experimentally developed for reliable multicast in IPv4, discussed in Section 3.2.2.3, can be used in IPv6 as well 🥰
3.2.5.1. Protocol-Independent Multicast Routing
Okay so a multicast routing protocol has two basic jobs 🫶: building the multicast distribution tree and forwarding multicast traffic. Usually there's a control plane that builds the distribution trees and a forwarding plane that uses that tree when it moves multicast traffic 🌸
Here's how the multicast model works ✨. Hosts say they're interested in receiving multicast traffic from a source by sending a Join message to their first-hop router. That router then sends its own Join message upstream toward the root of the tree, grafting itself (the leaf node) onto the distribution tree for the group. Then data flows down the tree toward the leaf nodes, and they forward it onto their local network for delivery 🦋
The very first multicast model deployed on the Internet was called Any-Source Multicast (ASM) 💅. In ASM, any host could send to the group, and inter-domain multicast was kinda difficult 😭. Protocols like Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised) [RFC3973] and Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised) [RFC4601] were designed for the ASM model.
Lots of modern multicast deployments use Source-Specific Multicast (PIM-SSM) [RFC3569][RFC4608] 👑. In the SSM model, a host expresses interest in a "channel", which is made up of a source (S) and a group (G). Distribution trees are rooted at the sending host (called an "(S,G) tree") 🧚. Since only the source S can send to the group, SSM has inherent anti-jamming capability 💪. Inter-domain multicast is also simplified, because finding the (S,G) channel they want is the responsibility of the receivers (rather than the networks) 💖. This implies that SSM requires some form of directory service so receivers can find the (S,G) channels 🙈
3.2.6. Adaptation to Lower-Layer Networks and Link Layer Protocols
Generally, the layered architecture of the Internet lets the IPS run over any appropriate layer two architecture 🍓. Being able to change the link or physical layer without rethinking the network layer, transports, or applications has been a huge benefit on the Internet, honestly iconic 🌈
Examples of link layer adaptation technology include:
- Ethernet/IEEE 802.3: IPv4 has run on each link layer environment that uses the Ethernet header (which is to say 10 and 100 MBPS wired Ethernet, 1 and 10 GBPS wired Ethernet, and the various versions of IEEE 802.11) using [RFC0894]. IPv6 does the same using [RFC2464] 🔌
- PPP: The IETF has defined a serial line protocol, the Point-to-Point Protocol (PPP) [RFC1661], that uses High-Level Data Link Control (bit-synchronous or byte synchronous) framing. The IPv4 adaptation specification is [RFC1332], and the IPv6 adaptation specification is [RFC5072]. Current use of this protocol is in traditional serial lines, authentication exchanges in DSL networks using PPP Over Ethernet (PPPoE) [RFC2516], and the Digital Signaling Hierarchy (generally referred to as Packet-on-SONET/SDH) using PPP over SONET/SDH [RFC2615] 📞
- IEEE 802.15.4: The adaptation specification for IPv6 transmission over IEEE 802.15.4 Networks is [RFC4944] 🧸
Numerous other adaptation specifications exist, including ATM, Frame Relay, X.25, other standardized and proprietary LAN technologies, and others 🌸
3.3. Transport Layer
This section breaks down the functionality of UDP, TCP, SCTP, and DCCP 💅. UDP and TCP are the best known and most widely used in the Internet today, while SCTP and DCCP are newer protocols that were built for specific purposes 🦋. Other transport protocols can be built when required ✨
3.3.1. User Datagram Protocol (UDP)
The User Datagram Protocol [RFC0768] and the Lightweight User Datagram Protocol [RFC3828] are properly not "transport" protocols in the sense of "a set of rules governing the exchange or transmission of data electronically between devices". They're labels that provide for multiplexing of applications directly on the IP layer, with transport functionality embedded in the application 🧩
Many exchange designs have been built using UDP, and many of them have not worked out 💀. As a result, using UDP really should be treated as designing a new transport. Advice on using UDP in new applications can be found in Unicast UDP Usage Guidelines for Application Designers [RFC5405] 📝
Datagram Transport Layer Security [RFC5238] can be used to prevent eavesdropping, tampering, or message forgery for applications that run over UDP 🔒. Alternatively, UDP can run over IPsec 🫶
3.3.2. Transmission Control Protocol (TCP)
TCP [RFC0793] is the predominant transport protocol used in the Internet, no cap 👑. It's "reliable", as the term is used in protocol design: it delivers data to its peer and provides acknowledgement to the sender, or it dies trying 😭. It has extensions for Congestion Control [RFC5681] and Explicit Congestion Notification [RFC3168] 🌊
The user interface for TCP is a byte stream interface -- an application using TCP might "write" to it several times, only to have the data compacted into a common segment and delivered as such to its peer 🙈. For message-stream interfaces, ACSE/ROSE uses the ISO Transport Service on TCP [RFC1006][RFC2126] in the application 🧃
Transport Layer Security [RFC5246] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, TCP can run over IPsec. Additionally, [RFC4987] discusses mechanisms similar to SCTP's and DCCP's "cookie" approach that may be used to secure TCP sessions against flooding attacks 🛡️
Finally, TCP has been the subject of ongoing research and development since it was written. The Roadmap for TCP Specification Documents [RFC4614] captures this history, and is intended to be a guide to current and future developers in the area 🗺️✨
3.3.3. Stream Control Transmission Protocol (SCTP)
SCTP [RFC4960] is a more recent reliable transport protocol that you can imagine as a TCP-like context containing multiple separate and independent message streams (unlike TCP's byte streams) 🎀. Its design includes appropriate congestion avoidance behavior and resistance to flooding and masquerade attacks 💅. Since it uses a message stream interface, it may also be more appropriate for the ISO Transport Service than using RFC 1006/2126 to turn TCP's octet streams into a message interface 🧁
SCTP offers several delivery options. The basic service is sequential non-duplicated delivery of messages within a stream, for each stream in use. Since streams are independent, one stream may pause due to head-of-line blocking while another stream in the same session keeps delivering data 🏃♀️. SCTP also provides a mechanism for bypassing the sequenced delivery service. User messages sent using this mechanism are delivered to the SCTP user as soon as they're received ⚡
SCTP implements a simple "cookie" mechanism meant to limit the effectiveness of flooding attacks by mutual authentication. This demonstrates that the application is connected to the same peer, but does not identify the peer 🍪. Mechanisms also exist for Dynamic Address Reconfiguration [RFC5061], which lets peers change addresses during the session and still keep connectivity 🔁. Transport Layer Security [RFC3436] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, SCTP can run over IPsec 🔐
3.3.4. Datagram Congestion Control Protocol (DCCP)
DCCP [RFC4340] is an "unreliable" transport protocol (e.g., one that does not guarantee message delivery) that provides bidirectional unicast connections of congestion-controlled unreliable datagrams 🦋. It's suitable for applications that transfer fairly large amounts of data and that can benefit from control over the tradeoff between timeliness and reliability ⏱️
DCCP implements a simple "cookie" mechanism meant to limit the effectiveness of flooding attacks by mutual authentication. This demonstrates that the application is connected to the same peer, but does not identify the peer 🍪. Datagram Transport Layer Security [RFC5238] can be used to prevent eavesdropping, tampering, or message forgery. Alternatively, DCCP can run over IPsec 🔒
3.4. Infrastructure
3.4.1. Domain Name System
To help with network management and operations, the Internet community has defined the Domain Name System (DNS) [RFC1034] [RFC1035] 🌐. Names are hierarchical: a name like example.com is registered with a .com registrar, and within the associated network other names like baldur.cincinatti.example.com can be defined, with obvious hierarchy 🌳. Security extensions, which let a registry sign the records it contains and in doing so demonstrate their authenticity, are defined by the DNS Security Extensions [RFC4033] [RFC4034] [RFC4035] 🔏
Devices can also optionally update their own DNS record. For example, a sensor that is using Stateless Address Autoconfiguration [RFC4862] to create an address might want to associate it with a name using DNS Dynamic Update [RFC2136] or DNS Secure Dynamic Update [RFC3007] 🤖
3.4.2. Dynamic Host Configuration
As discussed in Section 3.2.2, IPv4 address assignment is generally performed using DHCP [RFC2131]. By contrast, Section 3.2.3 points out that IPv6 address assignment can be accomplished using either autoconfiguration [RFC4862] [RFC4941] or DHCPv6 [RFC3315]. The best argument for autoconfiguration is a large number of systems that need little more than a random number as an address, while the argument for DHCP is administrative control 🎛️✨
There are other parameters that may need to be allocated to hosts that require administrative configuration. Examples include the addresses of DNS servers, keys for Secure DNS, and Network Time servers 🧚
3.4.3. Network Time
The Network Time Protocol was originally designed by Dave Mills of the University of Delaware and CSNET, implementing a temporal metric in the Fuzzball Routing Protocol and generally coordinating time experiments ⏰. The current versions of the time protocol are the Network Time Protocol [RFC5905] 🕰️
3.5. Network Management
The IETF has developed two protocols for network management: SNMP and NETCONF 🛠️. SNMP is discussed in Section 3.5.1, and NETCONF is discussed in Section 3.5.2 💜
3.5.1. Simple Network Management Protocol (SNMP)
The Simple Network Management Protocol was originally specified in the late 1980's and has passed through several revisions. It's specified in several documents 📚:
- An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks [RFC3411]
- Message Processing and Dispatching [RFC3412]
- SNMP Applications [RFC3413]
- User-based Security Model (USM) for SNMP version 3 [RFC3414]
- View-based Access Control Model (VACM) [RFC3415]
- Version 2 of the SNMP Protocol Operations [RFC3416]
- Transport Mappings [RFC3417]
- Management Information Base (MIB) [RFC3418]
SNMP provides capabilities for polled and event-driven activities, and for both monitoring and configuration of systems in the field 🔥. Historically, it has been used primarily for monitoring nodes in a network 👀. Messages and their constituent data are encoded using a profile of ASN.1 🎀
3.5.2. Network Configuration (NETCONF) Protocol ✨
okay so the NETCONF Configuration Protocol is specified in one main doc, and then there are supporting docs that explain how to carry it over the IPS 🫶 bestie, here's the whole crew:
- NETCONF Configuration Protocol [RFC4741]
- Using the NETCONF Configuration Protocol over Secure SHell (SSH) [RFC4742]
- Using NETCONF over the Simple Object Access Protocol (SOAP) [RFC4743]
- Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP) [RFC4744]
- NETCONF Event Notifications [RFC5277]
- NETCONF over Transport Layer Security (TLS) [RFC5539]
- Partial Lock Remote Procedure Call (RPC) for NETCONF [RFC5717]
so the vibe is: NETCONF was built because operators were like "can we please have one common configuration protocol that's based on ASCII text?" 🙈 and not ASN.1. lowkey iconic. Basically it carries XML-encoded remote procedure call (RPC) data 💅 And because of Smart Grid requirements, people are thinking about a variant of the protocol that could handle polled and event-driven management, and for both monitoring and configuring systems out in the field 🔥
3.6. Service and Resource Discovery 🦋
Service and resource discovery are literally some of the most important protocols for constrained resource self-organizing networks 👑 That includes a bunch of sensor networks, plus the Home Area Networks (HANs), Building Area Networks (BANs), and Field Area Networks (FANs) that Smart Grid architects have dreamed up 🌈
3.6.1. Service Discovery 🧚
Service discovery protocols are designed for the automatic configuration and detection of devices, and of the services those discovered devices offer 💖 A lot of the time, service discovery is done by so-called "constrained resource" devices (aka devices with limited processing power, memory, and power resources) 🥺
In general, service discovery is about resolving and distributing host names via multicast DNS [MULTICAST-DNS], and about automatically locating network services via DHCP (Section 3.4.2), the DNS Service Discovery (DNS-SD) [DNS-SD] (which is part of Apple's Bonjour technology) 🍎, and the Service Location Protocol (SLP) [RFC2608] ✨
3.6.2. Resource Discovery 💜
Resource Discovery is all about finding the resources that end-points offer, and it's extremely important in machine-to-machine closed-loop applications (aka the ones with no humans in the loop) 🤖 The goals of resource discovery protocols include:
- Simplicity of creation and maintenance of resources
- Commonly understood semantics
- Conformance to existing and emerging standards
- International scope and applicability
- Extensibility
- Interoperability among collections and indexing systems
the Constrained Application Protocol (CoAP) [COAP] is being developed in the IETF with all of these goals in mind 🎀 CoAP is designed for constrained resource networks and for machine-to-machine apps like smart energy and building automation ⚡ It gives you a RESTful transfer protocol [RESTFUL], a built-in resource discovery protocol, and web concepts like URIs and content-types 🌸 CoAP does both unicast and multicast resource discovery, and it can filter on attributes of resource descriptions too 🫶 And finally, CoAP resource discovery can also be used to discover HTTP resources. iconic, honestly 👑
For simplicity, CoAP assumes that all CoAP servers listen on the default CoAP port, or that they've been configured or discovered some other way, like with DNS Service Discovery (DNS-SD) [DNS-SD] 🧠
Resource discovery in CoAP works through well-known resources that describe the links a CoAP server offers 🔍 CoAP defines a well-known URI for discovery: "/.well-known/r" [RFC5785]. For example, the query [GET /.well-known/r] returns a list of links (representing resources) available from the queried CoAP server 💅 And a query like [GET /.well-known/r?n=Voltage] returns the resources named Voltage ⚡
3.7. Other Applications 🌈
There are so many applications that rely on the IP infrastructure but aren't really part of the IP infrastructure itself 💭 These applications can be useful in the context of the Smart Grid 🔌 The choices you make when building a profile of the Internet Profile Suite may affect how these applications can be used, so it matters 👀 A few of them are discussed here (this is not an exhaustive list, periodt) 🍓
3.7.1. Session Initiation Protocol 📞
The Session Initiation Protocol [RFC3261] [RFC3265] [RFC3853] [RFC4320] [RFC4916] [RFC5393] [RFC5621] is an application layer control (signaling) protocol for creating, modifying, and terminating multimedia sessions on the Internet. It's meant to be more scalable than H.323, which is so relatable 😭 Multimedia sessions can be voice, video, instant messaging, shared data, and/or event subscriptions 🎥 SIP can run on top of TCP, UDP, SCTP, or TLS over TCP. It's independent of the transport layer and of the underlying IPv4/v6 version 🦋 Honestly the transport protocol can even change as a SIP message travels between SIP entities from source to destination, which is giving main character energy ✨
SIP itself doesn't decide whether a session is voice or video, and it doesn't identify the actual endpoints' IP addresses either 🙈 That's the job of the Session Description Protocol (SDP) [RFC4566]. Inside the SDP (which SIP transports), codecs get offered and accepted (or not), and the port number and IP address where each endpoint wants to receive its Real-time Transport Protocol (RTP) [RFC3550] packets get determined 🎧 Adding Network Address Translation (NAT) to the profile, whether that's IPv4/IPv4, IPv4/IPv6 (as described in Section 3.2.1.3), or IPv6/IPv6, makes SIP/SDP deployment more complicated 😵💫 This is discussed further in [RFC2993] and [RFC5626] 📚
3.7.2. Extensible Messaging and Presence Protocol 💬
The Extensible Messaging and Presence Protocol (XMPP) [RFC6120] is a protocol for streaming Extensible Markup Language (XML) elements so you can swap structured information in close to real time between any two network endpoints 🚀 Because XMPP is a generalized, extensible framework for exchanging XML data, people have proposed it as an application structure for interchange between embedded devices and sensors 🔧 It's currently used for Instant Messaging and Presence [RFC6121] and a wide variety of real-time communication modes, like multi-user chat, publish-subscribe, alerts and notifications, service discovery, multimedia session management, device configuration, and remote procedure calls 🫧 XMPP supports channel encryption using TLS [RFC5246] and strong authentication (including PKIX certificate authentication) using SASL [RFC4422] 🔐 It also uses Unicode-compliant addresses and UTF-8 [RFC3629] data exchange for internationalization 🌏
XMPP also allows for End-to-End Signing and Object Encryption [RFC3923] 🔏, access to objects named using Uniform Resource Names (URN) [RFC4854] 🏷️, use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) [RFC5122] 🗂️, and the presentation of Notifications [RFC5437] 🔔
3.7.3. Calendaring 🗓️
Internet calendaring, as implemented in Apple iCal, Microsoft Outlook and Entourage, and Google Calendar, is specified in Internet Calendaring and Scheduling Core Object Specification (iCalendar) [RFC5545] 🎀 It's in the process of being updated to an XML schema in iCalendar XML Representation [xCAL] 🫶 Several protocols carry calendar events, including the iCalendar Transport-Independent Interoperability Protocol (iTIP) [RFC5546], the iCalendar Message-Based Interoperability Protocol (iMIP) [RFC6047], and open source work on the Atom Publishing Protocol [RFC5023] 💖
4. A Simplified View of the Business Architecture ✨
okay bestie, the Internet is literally a network of networks 🌐, and each one is operated independently. The fun part is that the underlying Internet architecture puts no restrictions on how networks get interconnected 💅. Interconnection is a business decision 💼, so the Internet's interconnection architecture can be thought of as a "business structure" for the Internet.
Central to that structure are the networks that provide connectivity to other networks, called "transit networks" 👑. They sell bulk bandwidth and routing services to each other, and to other networks as customers. Around the periphery of the transit network are companies, schools, and other networks that serve individuals directly 🎀. These can generally be split into "enterprise networks" and "access networks". Enterprise networks provide "free" connectivity to their own employees or members, plus services like electronic mail, web services, and so on 📧. Access networks sell broadband connectivity (DSL, Cable Modem, 802.11 wireless, or 3GPP wireless) or "dial" services (including PSTN dial-up and ISDN) to subscribers 📡. Those subscribers are typically residential or small office/home office (SOHO) customers. Residential customers are basically entirely dependent on their access provider for all services 🥺, while a SOHO buys some services from the access provider and provides others for itself. Networks that sell transit services to nobody else (SOHO, residential, and enterprise networks) are generally called "edge networks" 🍓. Transit networks count as the "core" of the Internet, and access networks sit between the two 🧚. Figure 3 shows this general structure.
------ ------
/ \ / \
/--\ / \ / \
|SOHO|---+ Access | |Enterprise|
\--/ | Service | | Network |
/--\ | Provider| | |
|Home|---+ | ------ | |
\--/ \ +---+ +---+ /
\ / / \ \ /
------ | Transit | ------
| Service |
| Provider |
| |
\ /
\ /
------
Figure 3: Conceptual Model of Internet BusinessesA specific example is shown in a traceroute from a home to a nearby school 🏫. Internet connectivity in Figure 4 passes through:
- the home network,
- Cox Communications, an access network using Cable Modem technology,
- TransitRail, a commodity peering service for research and education (R&E) networks,
- Corporation for Education Network Initiatives in California (CENIC), a transit provider for educational networks, and
- the University of California at Santa Barbara, which in this context might be viewed as an access network for its students and faculty or as an enterprise network.
<stealth-10-32-244-218:> fred% traceroute www.ucsb.edu
traceroute to web.ucsb.edu (128.111.24.41),
64 hops max, 40 byte packets
1 fred-vpn (10.32.244.217) 1.560 ms 1.108 ms 1.133 ms
2 wsip-98-173-193-1.sb.sd.cox.net (98.173.193.1) 12.540 ms ...
3 68.6.13.101 ...
4 68.6.13.129 ...
5 langbbr01-as0.r2.la.cox.net ...
6 calren46-cust.lsanca01.transitrail.net ...
7 dc-lax-core1--lax-peer1-ge.cenic.net ...
8 dc-lax-agg1--lax-core1-ge.cenic.net ...
9 dc-ucsb--dc-lax-dc2.cenic.net ...
10 r2--r1--1.commserv.ucsb.edu ...
11 574-c--r2--2.commserv.ucsb.edu ...
12 * * *
Figure 4: Traceroute from Residential Customer to Educational
InstitutionAnother specific example could be shown in a traceroute from the home through a Virtual Private Network (VPN tunnel) from the home 🔐. It crosses Cox Cable (an access network) and Pacific Bell (a transit network), and terminates in Cisco Systems (an enterprise network). A traceroute of that path doesn't show it, because the path is invisible within the VPN and the VPN's contents are invisible to the networks on the path due to encryption 🙈. Instead, the traceroute in Figure 5 is entirely within Cisco's internal network.
<stealth-10-32-244-218:~> fred% traceroute irp-view13
traceroute to irp-view13.cisco.com (171.70.120.60),
64 hops max, 40 byte packets
1 fred-vpn (10.32.244.217) 2.560 ms 1.100 ms 1.198 ms
<tunneled path through Cox and Pacific Bell>
2 ****
3 sjc24-00a-gw2-ge2-2 (10.34.251.137) 26.298 ms...
4 sjc23-a5-gw2-g2-1 (10.34.250.78) 25.214 ms ...
5 sjc20-a5-gw1 (10.32.136.21) 23.205 ms ...
6 sjc12-abb4-gw1-t2-7 (10.32.0.189) 46.028 ms ...
7 sjc5-sbb4-gw1-ten8-2 (171.*.*.*) 26.700 ms ...
8 sjc12-dc5-gw2-ten3-1 ...
9 sjc5-dc4-gw1-ten8-1 ...
10 irp-view13 ...
Figure 5: Traceroute across VPNNote that in both cases, the home network uses private address space [RFC1918] while other networks generally use public address space 🏠. Three middleware technologies are in use here: a firewall, a Network Address Translator (NAT), and a Virtual Private Network (VPN) 🧱.
Firewalls are generally sold as, and considered by many to be, a security technology 🛡️. This is based on the fact that a firewall imposes a border between two administrative domains. Typically, a firewall gets deployed between a residential, SOHO, or enterprise network and its access or transit provider. In essence, a firewall is a data diode 🚪, imposing a policy on which sessions may pass between a protected domain and the rest of the Internet. Simple policies generally permit sessions to be originated from the protected network but not from the outside. More complex policies may permit additional sessions from the outside, such as electronic mail to a mail server or a web session to a web server, and may prevent certain applications from global access even though they originate from the inside.
Note that the effectiveness of firewalls remains controversial 🥊. While network managers often insist on deploying firewalls because they impose a boundary, others point out that their value as a security solution is debatable. This is because most attacks come from behind the firewall. In addition, firewalls do not protect against application layer attacks such as viruses carried in email. Thus, as a security solution, firewalls are justified as a layer in defense in depth. That is, while an end system must in the end be responsible for its own security, a firewall can inhibit or prevent certain kinds of attacks, for example the consumption of CPU time on a critical server.
Key documents describing firewall technology and the issues it poses include:
- IP Multicast and Firewalls [RFC2588]
- Benchmarking Terminology for Firewall Performance [RFC2647]
- Behavior of and Requirements for Internet Firewalls [RFC2979]
- Benchmarking Methodology for Firewall Performance [RFC3511]
- Mobile IPv6 and Firewalls: Problem Statement [RFC4487]
- NAT and Firewall Traversal Issues of Host Identity Protocol Communication [RFC5207]
Network Address Translation is a technology that was developed in response to ISP behaviors in the mid-1990's 🕰️. When [RFC1918] was published, many ISPs started handing out single or small numbers of addresses, and edge networks were forced to translate. Over time, this became considered a good thing, or at least not a bad thing 🌸. It amplified the public address space, and it was sold as if it were a firewall. It of course is not 🙃. Traditional dynamic NATs only translate between internal and external session address/port tuples during the detected duration of the session. That session state may exist in the network much longer than it exists on the end system, and as a result it constitutes an attack vector 😬. The design, value, and limitations of network address translation are described in:
- IP Network Address Translator Terminology and Considerations [RFC2663]
- Traditional IP Network Address Translator [RFC3022]
- Protocol Complications with the IP Network Address Translator [RFC3027]
- Network Address Translator Friendly Application Design Guidelines [RFC3235]
- IAB Considerations for Network Address Translation [RFC3424]
- IPsec-Network Address Translation Compatibility Requirements [RFC3715]
- Network Address Translation Behavioral Requirements for Unicast UDP [RFC4787]
- State of Peer-to-Peer Communication across Network Address Translators [RFC5128]
- IP Multicast Requirements for a Network Address Translator and a Network Address Port Translator [RFC5135]
Virtual Private Networks come in many forms, but what they have in common is that they are generally tunneled over the Internet backbone 🚇. So, as in Figure 5, connectivity appears to be entirely within the edge network, although it is in fact crossing a service provider's network 🎭. Examples include IPsec tunnel-mode encrypted tunnels, IP-in-IP or GRE tunnels, and MPLS LSPs [RFC3031][RFC3032] 🧁.
5. Security Considerations 🔒
Security is addressed in some detail in Section 2.2 and Section 3.1.
6. Acknowledgements 🫶
Review comments were made by Adrian Farrel, Andrew Yourtchenko, Ashok Narayanan, Bernie Volz, Chris Lonvick, Dan Romascanu, Dave McGrew, Dave Oran, David Harrington, David Su, Don Sturek, Francis Cleveland, Hemant Singh, James Polk, Jari Arkko, John Meylor, Joseph Salowey, Julien Abeille, Kerry Lynn, Lars Eggert, Magnus Westerlund, Murtaza Chiba, Paul Duffy, Paul Hoffman, Peter Saint-Andre, Ralph Droms, Robert Sparks, Russ White, Sean Turner, Sheila Frankel, Stephen Farrell, Tim Polk, Toerless Eckert, Tom Herbst, Vint Cerf, and Yoshihiro Ohba. Several of the individuals suggested text, which was very useful, as the authors don't claim to know half as much as their reviewers collectively do 🤓💖.
7. References 📚
7.1. Normative References
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122,
October 1989.
[RFC1123] Braden, R., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123,
October 1989.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
RFC 1812, June 1995.
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.7.2. Informative References
[6LOWPAN-HC] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams in Low Power and Lossy Networks
(6LoWPAN)", Work in Progress, February 2011.Okay bestie, the reference shelf keeps going 📚💅
[ABFAB-ARCH] Howlett, J., Hartman, S., Tschofenig, H., and E.
Lear, "Application Bridging for Federated Access
Beyond Web (ABFAB) Architecture", Work in Progress,
March 2011.
[AES-CCM-ECC] McGrew, D., Bailey, D., Campagna, M., and R. Dugal,
"AES-CCM ECC Cipher Suites for TLS", Work
in Progress, January 2011.
[COAP] Shelby, Z., Hartke, K., Bormann, C., and B. Frank,
"Constrained Application Protocol (CoAP)", Work
in Progress, March 2011.
[DIME-BASE] Fajardo, V., Ed., Arkko, J., Loughney, J., and G.
Zorn, "Diameter Base Protocol", Work in Progress,
January 2011.
[DNS-SD] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", Work in Progress, February 2011.
[DTLS] Rescorla, E. and N. Modadugu, "Datagram Transport
Layer Security version 1.2", Work in Progress,
March 2011.
[DYMO] Chakeres, I. and C. Perkins, "Dynamic MANET On-
demand (DYMO) Routing", Work in Progress, July 2010.
[IEC61850] Wikipedia, "Wikipedia Article: IEC 61850",
June 2011, <http://en.wikipedia.org/w/
index.php?title=IEC_61850&oldid=433437827>.
[IEC62351-3] International Electrotechnical Commission Technical
Committee 57, "POWER SYSTEMS MANAGEMENT AND
ASSOCIATED INFORMATION EXCHANGE. DATA AND
COMMUNICATIONS SECURITY -- Part 3: Communication
network and system security Profiles including
TCP/IP", May 2007.
[IEEE802.1X] Institute of Electrical and Electronics Engineers,
"IEEE Standard for Local and Metropolitan Area
Networks - Port based Network Access Control",
IEEE Standard 802.1X-2010, February 2010.
[IP-SEC] Gont, F., "Security Assessment of the Internet
Protocol Version 4", Work in Progress, April 2011.
[IPv6-NODE-REQ] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6
Node Requirements", Work in Progress, May 2011.
[MULTICAST-DNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work
in Progress, February 2011.
[Model] SGIP, "Smart Grid Architecture Committee: Conceptual
Model White Paper http://collaborate.nist.gov/
twiki-sggrid/pub/SmartGrid/
SGIPConceptualModelDevelopmentSGAC/
Smart_Grid_Conceptual_Model_20100420.doc".
[OAUTHv2] Hammer-Lahav, E., Recordon, D., and D. Hardt, "The
OAuth 2.0 Authorization Protocol", Work in Progress,
May 2011.
[RESTFUL] Fielding, "Architectural Styles and the Design of
Network-based Software Architectures", 2000.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6,
RFC 768, August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC0792] Postel, J., "Internet Control Message Protocol",
STD 5, RFC 792, September 1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol:
Or converting network protocol addresses to 48.bit
Ethernet address for transmission on Ethernet
hardware", STD 37, RFC 826, November 1982.
[RFC0894] Hornig, C., "Standard for the transmission of IP
datagrams over Ethernet networks", STD 41, RFC 894,
April 1984.
[RFC1006] Rose, M. and D. Cass, "ISO transport services on top
of the TCP: Version 3", STD 35, RFC 1006, May 1987.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1058] Hedrick, C., "Routing Information Protocol",
RFC 1058, June 1988.
[RFC1112] Deering, S., "Host extensions for IP multicasting",
STD 5, RFC 1112, August 1989.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP
and dual environments", RFC 1195, December 1990.
[RFC1332] McGregor, G., "The PPP Internet Protocol Control
Protocol (IPCP)", RFC 1332, May 1992.
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)",
STD 51, RFC 1661, July 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API
Mechanism", RFC 1964, June 1996.
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6",
RFC 2080, January 1997.
[RFC2126] Pouffary, Y. and A. Young, "ISO Transport Service on
top of TCP (ITOT)", RFC 2126, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS
UPDATE)", RFC 2136, April 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
April 1998.
[RFC2357] Mankin, A., Romanov, A., Bradner, S., and V. Paxson,
"IETF Criteria for Evaluating Reliable Multicast
Transport and Application Protocols", RFC 2357,
June 1998.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460,
December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for
Differentiated Services", RFC 2475, December 1998.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D.,
Simone, D., and R. Wheeler, "A Method for
Transmitting PPP Over Ethernet (PPPoE)", RFC 2516,
February 1999.
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4
Multiprotocol Extensions for IPv6 Inter-Domain
Routing", RFC 2545, March 1999.
[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S.,
and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol -
OCSP", RFC 2560, June 1999.
[RFC2588] Finlayson, R., "IP Multicast and Firewalls",
RFC 2588, May 1999.
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day,
"Service Location Protocol, Version 2", RFC 2608,
June 1999.
[RFC2615] Malis, A. and W. Simpson, "PPP over SONET/SDH",
RFC 2615, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
June 1999.
[RFC2647] Newman, D., "Benchmarking Terminology for Firewall
Performance", RFC 2647, August 1999.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations",
RFC 2663, August 1999.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710,
October 1999.
[RFC2743] Linn, J., "Generic Security Service Application
Program Interface Version 2, Update 1", RFC 2743,
January 2000.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)",
RFC 2784, March 2000.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service
(RADIUS)", RFC 2865, June 2000.
[RFC2979] Freed, N., "Behavior of and Requirements for
Internet Firewalls", RFC 2979, October 2000.
[RFC2993] Hain, T., "Architectural Implications of NAT",
RFC 2993, November 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP
Network Address Translator (Traditional NAT)",
RFC 3022, January 2001.
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol
Complications with the IP Network Address
Translator", RFC 3027, January 2001.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon,
"Multiprotocol Label Switching Architecture",
RFC 3031, January 2001.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label
Stack Encoding", RFC 3032, January 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The
Addition of Explicit Congestion Notification (ECN)
to IP", RFC 3168, September 2001.
[RFC3235] Senie, D., "Network Address Translator (NAT)-
Friendly Application Design Guidelines", RFC 3235,
January 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G.,
Johnston, A., Peterson, J., Sparks, R., Handley, M.,
and E. Schooler, "SIP: Session Initiation Protocol",
RFC 3261, June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-
Specific Event Notification", RFC 3265, June 2002.
[RFC3275] Eastlake, D., Reagle, J., and D. Solo, "(Extensible
Markup Language) XML-Signature Syntax and
Processing", RFC 3275, March 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration
Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and
A. Thyagarajan, "Internet Group Management Protocol,
Version 3", RFC 3376, October 2002.- [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
- [RFC3412] Case, J., Harrington, D., Presuhn, R., and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
- [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
- [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
- [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
- [RFC3416] Presuhn, R., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002.
- [RFC3417] Presuhn, R., "Transport Mappings for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3417, December 2002.
- [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
- [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
- [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.
- [RFC3453] Luby, M., Vicisano, L., Gemmell, J., Rizzo, L., Handley, M., and J. Crowcroft, "The Use of Forward Error Correction (FEC) in Reliable Multicast", RFC 3453, December 2002.
- [RFC3511] Hickman, B., Newman, D., Tadjudin, S., and T. Martin, "Benchmarking Methodology for Firewall Performance", RFC 3511, April 2003.
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
- [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003.
- [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC 3561, July 2003.
- [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003.
- [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
- [RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003.
- [RFC3626] Clausen, T. and P. Jacquet, "Optimized Link State Routing Protocol (OLSR)", RFC 3626, October 2003.
- [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
- [RFC3715] Aboba, B. and W. Dixon, "IPsec-Network Address Translation (NAT) Compatibility Requirements", RFC 3715, March 2004.
- [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
- [RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, July 2004.
- [RFC3853] Peterson, J., "S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)", RFC 3853, July 2004.
- [RFC3923] Saint-Andre, P., "End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)", RFC 3923, October 2004.
- [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
- [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol Independent Multicast - Dense Mode (PIM-DM): Protocol Specification (Revised)", RFC 3973, January 2005.
- [RFC4017] Stanley, D., Walker, J., and B. Aboba, "Extensible Authentication Protocol (EAP) Method Requirements for Wireless LANs", RFC 4017, March 2005.
- [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
- [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
- [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
- [RFC4108] Housley, R., "Using Cryptographic Message Syntax (CMS) to Protect Firmware Packages", RFC 4108, August 2005.
- [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
- [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
- [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, "Internet X.509 Public Key Infrastructure Certificate Management Protocol (CMP)", RFC 4210, September 2005.
- [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
- [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
- [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
- [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [RFC4307] Schiller, J., "Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)", RFC 4307, December 2005.
- [RFC4320] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, January 2006.
- [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
- [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security", RFC 4347, April 2006.
- [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
- [RFC4410] Pullen, M., Zhao, F., and D. Cohen, "Selectively Reliable Multicast Protocol (SRMP)", RFC 4410, February 2006.
- [RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
- [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
- [RFC4487] Le, F., Faccin, S., Patil, B., and H. Tschofenig, "Mobile IPv6 and Firewalls: Problem Statement", RFC 4487, May 2006.
- [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", RFC 4492, May 2006.
- [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
- [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
- [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
- [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
- [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", RFC 4604, August 2006.
- [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006.
- [RFC4608] Meyer, D., Rockell, R., and G. Shepherd, "Source-Specific Protocol Independent Multicast in 232/8", BCP 120, RFC 4608, August 2006.
- [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
- [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
- [RFC4742] Wasserman, M. and T. Goddard, "Using the NETCONF Configuration Protocol over Secure SHell (SSH)", RFC 4742, December 2006.
- [RFC4743] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006.
- [RFC4744] Lear, E. and K. Crozier, "Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)", RFC 4744, December 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 🌸
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. 💅
[RFC4835] Manral, V., "Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 4835, April 2007. 🔐
[RFC4854] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)", RFC 4854, April 2007. 🦋
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. ✨
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. 🎀
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007. 🫶
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007. 🧚
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. 🙈
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, September 2007. 🌈
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. 💜
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common Mitigations", RFC 4987, August 2007. 🔥
[RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing Protocol", RFC 5023, October 2007. 🍓
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007. ⭐
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007. 🌸
[RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008. 💅
[RFC5128] Srisuresh, P., Ford, B., and D. Kegel, "State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)", RFC 5128, March 2008. 🦋
[RFC5135] Wing, D. and T. Eckert, "IP Multicast Requirements for a Network Address Translator (NAT) and a Network Address Port Translator (NAPT)", BCP 135, RFC 5135, February 2008. ✨
[RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008. 🎀
[RFC5207] Stiemerling, M., Quittek, J., and L. Eggert, "NAT and Firewall Traversal Issues of Host Identity Protocol (HIP) Communication", RFC 5207, April 2008. 🫶
[RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS Authentication Protocol", RFC 5216, March 2008. 🧚
[RFC5238] Phelan, T., "Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)", RFC 5238, May 2008. 🙈
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 🌈
[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC)", RFC 5272, June 2008. 💜
[RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event Notifications", RFC 5277, July 2008. 🔥
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. 👑
[RFC5289] Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, August 2008. 🍓
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008. ⭐
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. 🌸
[RFC5393] Sparks, R., Lawrence, S., Hawrylyshen, A., and B. Campen, "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies", RFC 5393, December 2008. 💅
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008. 🦋
[RFC5430] Salter, M., Rescorla, E., and R. Housley, "Suite B Profile for Transport Layer Security (TLS)", RFC 5430, March 2009. ✨
[RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", RFC 5433, February 2009. 🎀
[RFC5437] Saint-Andre, P. and A. Melnikov, "Sieve Notification Mechanism: Extensible Messaging and Presence Protocol (XMPP)", RFC 5437, January 2009. 🫶
[RFC5539] Badra, M., "NETCONF over Transport Layer Security (TLS)", RFC 5539, May 2009. 🧚
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009. 🙈
[RFC5546] Daboo, C., "iCalendar Transport-Independent Interoperability Protocol (iTIP)", RFC 5546, December 2009. 🌈
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. 💜
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010. 🔥
[RFC5621] Camarillo, G., "Message Body Handling in the Session Initiation Protocol (SIP)", RFC 5621, September 2009. 👑
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009. 🍓
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009. ⭐
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. 🌸
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion Control", RFC 5681, September 2009. 💅
[RFC5717] Lengyel, B. and M. Bjorklund, "Partial Lock Remote Procedure Call (RPC) for NETCONF", RFC 5717, December 2009. 🦋
[RFC5740] Adamson, B., Bormann, C., Handley, M., and J. Macker, "NACK-Oriented Reliable Multicast (NORM) Transport Protocol", RFC 5740, November 2009. ✨
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. 🎀
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010. 🫶
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. 🧚
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010. 🙈
[RFC5849] Hammer-Lahav, E., "The OAuth 1.0 Protocol", RFC 5849, April 2010. 🌈
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010. 💜
[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010. 🔥
[RFC5932] Kato, A., Kanda, M., and S. Kanno, "Camellia Cipher Suites for TLS", RFC 5932, June 2010. 👑
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010. 🍓
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. ⭐
[RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", RFC 5998, September 2010. 🌸
[RFC6031] Turner, S. and R. Housley, "Cryptographic Message Syntax (CMS) Symmetric Key Package Content Type", RFC 6031, December 2010. 💅
[RFC6047] Melnikov, A., "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 6047, December 2010. 🦋
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. ✨
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011. 🎀
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. 🫶
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011. 🧚
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC RFC6144, April 2011. 🙈
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. 🌈
[RFC6146] Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. 💜
Continuing the References 💖
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011.
[RPL] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", Work in Progress, March 2011.
[SP-MULPIv3.0] CableLabs, "DOCSIS 3.0 MAC and Upper Layer Protocols Interface Specification, CM-SP-MULPIv3.0-I10- 090529", May 2009.
[SmartGrid] Wikipedia, "Wikipedia Article: Smart Grid", February 2011, <http://en.wikipedia.org/w/ index.php?title=Smart_grid&oldid=415838933>.
[TCP-SEC] Gont, F., "Security Assessment of the Transmission Control Protocol (TCP)", Work in Progress, January 2011.
[r1822] Bolt Beranek and Newman Inc., "Interface Message Processor -- Specifications for the interconnection of a host and a IMP, Report No. 1822", January 1976.
[xCAL] Daboo, C., Douglass, M., and S. Lees, "xCal: The XML format for iCalendar", Work in Progress, April 2011.
Appendix A. Example: Advanced Metering Infrastructure ⚡🏠
okay so this appendix is a worked example of how the Internet Protocol Suite could run in something like the Smart Grid's Advanced Metering Infrastructure (AMI). 🔌 There are several possible models, bestie, so don't think this is the only way it can look!
Figure 6 shows how the AMI reaches out toward a bunch of residences. 🏡 You've got the home itself with its Home Area Network (HAN), the Neighborhood Area Network (NAN) that the utility uses to reach the meter at the home, and the utility access network that connects a set of NANs to the utility itself. For this discussion, we're assuming the NAN has a distributed application running across a set of collectors. That's just one way it could be built, though, not the only way. ✨
---
A thermostats, appliances, etc
| ------+-----------------------------------
| |
|"HAN" | <--- Energy Services Interface (ESI)
| +---+---+
| | Meter | Meter is generally an ALG between the AMI and the HAN
| +---+---+
V \
--- \
A \ | /
| \ | /
| "NAN" +--+-+-+---+ Likely a router but could
| |Collector | be a front-end application
V +----+-----+ gateway for utility
--- \
A \ | /
| \ | /
|"AMI" +--+-+-+--+
| | AMI |
| | Headend |
V +---------+
---
Figure 6: The HAN, NAN, and Utility in the Advanced Metering
InfrastructureOkay, a few questions decide which model you end up with, and different answers give you different models. 💅 The big ones are:
- How does Demand Response work? Either:
- The utility sends pricing signals to the home,
- The utility sends pricing signals to individual devices (e.g., a Pluggable Electric Vehicle),
- The utility adjusts settings on individual appliances within the home.
- How does the utility access meters at the home?
- The AMI Headend manages the interfaces with the meters, collecting metering data and passing it on to the appropriate applications over the Enterprise Bus, or
- Distributed application support ("collectors") might access and summarize the information; this device might be managed by the utility or by a service between the utility and its customers.
In real life these models are idealized, so reality may mix some aspects of each model in specific cases. 🌈
The examples go like this:
- Appendix A.2 presumes that the HAN, the NAN, and the utility's network are separate administrative domains and speak application to application across those domains.
- Appendix A.3 repeats the first example, but presumes that the utility directly accesses appliances within the HAN from the collector.
- Appendix A.4 repeats the first example, but presumes that the collector directly forwards traffic as a router in addition to its distributed application chores. Note that this case implies numerous privacy and security concerns, so it's considered a less likely deployment model. 🙈
A.1. How to Structure a Network 🧱
Okay, so a huge consideration in the Internet has always been new link layer technologies showing up over time. 🦋 The ARPANET originally used a BBN proprietary link layer called BBN 1822 [r1822]. In the late 1970's, the ARPANET switched to X.25 as an interface to the 1822 network. Then, with the IEEE 802 series technologies arriving in the early 1980's, IP got deployed on Ethernet (IEEE 802.3), Token Ring (IEEE 802.5), and WiFi (IEEE 802.11), plus Arcnet, serial lines of various kinds, Frame Relay, and ATM. 🌸 The key thing here is that applications built to run on the Internet use APIs related to the IPS, so they need little or no change to keep working on a new link layer architecture or a mix of them. Iconic, honestly. 👑
The Smart Grid is likely to go through something similar. 🔋 Think of the Home Area Network (HAN) as a super easy to picture small network. Right now, the residential network technologies being proposed include IEEE P1901, various versions of IEEE 802.15.4, and IEEE 802.11. It's reasonable to expect other technologies to show up later too. As the Zigbee Alliance has learned (and as a result, it incorporated the IPS into Smart Energy Profile 2.0), there's a ton of value in providing a virtual address that maps to interfaces or nodes attached to each of those technologies. 🫶
Utility NAN
/
/
+----+-----+ +--+ +--+ +--+
| Meter | |D1| |D2| |D3|
+-----+----+ ++-+ ++-+ ++-+
| | | |
----+-+-------+----+----+---- IEEE 802.15.4
|
+--+---+
|Router+------/------ Residential Broadband
+--+---+
|
----+---------+----+----+---- IEEE P1901
| | |
++-+ ++-+ ++-+
|D4| |D5| |D6|
+--+ +--+ +--+
A thermostats, appliances, etc
| ------+----------------+------------------
|"HAN" | |
| +---+---+ +---+---+
| |Router | | Meter |
| |or EMS | | |
V +---+---+ +---+---+
--- | --- \
| ^ \ | /
| |"NAN" \ | /
---+--- | +--+-+-+---+
/ \ | |"Pole Top"|
| Internet| v +----+-----+
\ / ---
-------
Figure 7: Two Views of a Home Area NetworkOkay, so there are two possible communication models inside the HAN, and both are likely to be useful. 💜 Devices can talk directly to each other, or they can be managed by some central controller. A direct example is a light switch that commands a lamp to turn on or off. ⭐ An indirect example is a control application in a Customer or Building that takes telemetry from a thermostat, applies some form of policy, and controls the heating and air conditioning systems. Also, high-end appliances on the market today use residential broadband to talk to their manufacturers, and obviously the meter needs to talk to the utility. 🙌
Figure 7 shows two simple networks. One uses IEEE 802.15.4 and IEEE 1901 domains, and the other uses an arbitrary LAN inside the home, which could be IEEE 802.3/Ethernet, IEEE 802.15.4, IEEE 1901, IEEE 802.11, or anything else that makes sense in context. 🍓 Both show the connectivity between them as a router separate from the energy management system (EMS). That's just for clarity! The two could totally be combined into one system, and you could imagine appliances that want to talk to their manufacturers supporting both a HAN interface and a WiFi interface instead of depending on the router. These are all manufacturer design decisions, babe. 🎀
A.1.1. HAN Routing 🛣️
The HAN can be seen as talking to two kinds of non-HAN networks. The first is the home LAN, which may itself be attached to the Internet, and which will generally either derive its prefix from the upstream ISP or use a self-generated Unique Local Addressing (ULA). The second is the utility's NAN, which provides utility connectivity to the HAN through an ESI. In that case the HAN will be addressed by a self-generated ULA (note, though, that in some cases the ESI may also provide a prefix via DHCP [RFC3315]). On top of that, the HAN will have link-local addresses that can be used between neighboring nodes. In general, a HAN will be made up of 802.15.4, 802.11, and possibly other networks. 🧚
The ESI is a node on the user's residential network, and it typically won't provide stateful packet forwarding or firewall services between the HAN and the utility network(s). 🔥 In general, the ESI is a node on the home network, though in some cases the meter may act as the ESI. However, the ESI must be capable of understanding that most home networks are not 802.15.4 enabled (they're typically 802.11 networks instead), and that it must be capable of setting up ad hoc networks between various sensors in the home (e.g., between the meter and, say, a thermostat) in the event there aren't other networks available. Main character energy, fr fr. 💖
A.1.2. HAN Security ✨
Okay bestie, in ANY network there are a bunch of threats and a bunch of possible fixes 🔒. These include, at minimum:
- Link Layer: Why is your machine even able to talk in my network? 🙈 WiFi SSIDs often use some form of authenticated access control. That could be a simple encrypted password mechanism, or a combo of encryption and IEEE 802.1X+EAP-TLS Authentication/Authorization so that only authorized communicants can use it. If a LAN has a router attached, the router may also implement a firewall to filter remote accesses 🧱.
- Network Layer: Okay, so your machine is authorized to use my network... but why is it talking to MY machine? 🤨 IPsec is a way of ensuring that computers that can use a network are allowed to talk with each other. It may also enforce confidentiality, and it may provide VPN services to make a device or network appear to be part of a remote network 🕵️♀️.
- Application: Given that your machine is authorized access to my network and my machine, why is your application talking with my application? 👀 Just because our machines are allowed to talk for some applications doesn't mean they're allowed to for all applications. (D)TLS, https, and other such mechanisms let an application impose application-to-application controls, kinda like the network layer controls IPsec gives you 🦋.
- Remote Application: How do I know the data I received is the data you sent? 🥺 Especially in stuff like electronic mail, where data passes through a bunch of intermediaries that one may or may not actually want munging it (how many times have you seen a URL broken by a mail server? 💀). We have tools (DKIM, S/MIME, and W3C XML Signatures to name a few) to provide non-repudiability and integrity verification. This may also have legal ramifications: if a record of a meter reading is used in billing and the bill is disputed in court, one could imagine the court wanting proof that the record in fact came from that meter at that time and contained that data ⚖️.
- Application-specific security: Applications often provide security services of their own 🔐. Like, I can access a file system, but that doesn't mean I'm authorized to access everything in it. The file system may well prevent my access to some of its contents 📁. Routing protocols like BGP are obsessed with the question "what statements that my peer made am I willing to believe" 🤔, and monitoring protocols like SNMP may not be willing to answer every question they're asked, depending on access configuration.
Devices in the HAN want controlled access to the LAN in question for obvious reasons 🏠. In addition, there should be some form of mutual authentication between devices. The lamp controller will want to know that the light switch telling it to change state is the right light switch, for example 💡. The EMS may well want strong authentication of accesses. The parents may not want the children changing the settings, and while the utility and the customer are routinely granted access, other parties (especially parties with criminal intent) need to be excluded 🚫.
A.2. Model 1: AMI with Separated Domains 🧩
With the background given in Appendix A.1, we can now discuss the use of IP (IPv4 or IPv6) in the AMI. 💖
In this first model, consider the three domains in Figure 6 to literally be separate administrative domains, potentially operated by different entities. For example, the NAN could be a WiMAX network operated by a traditional telecom operator, the utility's network (including the collector) is its own, and the residential network is operated by the resident 🏘️. In this model, while communications between the collector and the Meter are normal, the utility has no other access to appliances in the home, and the collector doesn't directly forward messages from the NAN upstream 🚪.
In this case, as shown in Figure 7, it would make the most sense to design the collector, the Meter, and the EMS as hosts on the NAN. Design them as systems whose applications can originate and terminate exchanges or sessions in the NAN, but not forward traffic from or to other devices 🎀.
In such a configuration, Demand Response has to be performed by having the EMS accept messages such as price signals from the "pole top," apply some form of policy, and then orchestrate actions within the home ⚡. Another possibility is to have the EMS communicate with the ESI located in the meter. If the thermostat has high demand and low demand (day/night or morning/day/evening/night) settings, Demand Response might result in it moving to a lower demand setting, and the EMS might also turn off specified circuits in the home to diminish lighting 🌙.
In this scenario, Quality of Service (QoS) issues reportedly arise when high precedence messages must be sent through the collector to the home 😬. If the collector is occupied polling the meters or doing some other task, the application may not yield control of the processor to the application that services the message. Clearly, this is either an application or an Operating System problem. Applications need to be designed in a manner that doesn't block high precedence messages 🛠️. The collector also needs to use appropriate NAN services, if they exist, to provide the NAN QoS it needs. For example, if WiMax is in use, it might use a routine-level service for normal exchanges but a higher precedence service for these messages 🚀.
A.3. Model 2: AMI with Neighborhood Access to the Home 🏡
In this second model, let's imagine that the utility directly accesses appliances within the HAN 👀. Rather than expect an EMS to respond to price signals in Demand Response, it directly commands devices like air conditioners to change state, or throws relays on circuits to or within the home ⚡.
+----------+ +--+ +--+ +--+
| Meter | |D1| |D2| |D3|
+-----+----+ ++-+ ++-+ ++-+
| | | |
----+-+-------+----+----+---- IEEE 802.15.4
|
+--+---+
| +------/------ NAN
|Router|
| +------/------ Residential Broadband
+--+---+
|
----+--+------+----+----+---- IEEE P1901
| | | |
+-+-+ ++-+ ++-+ ++-+
|EMS| |D4| |D5| |D6|
+---+ +--+ +--+ +--+
Figure 8: Home Area NetworkIn this case, as shown in Figure 8, the Meter and EMS act as hosts on the HAN, and there is a router between the HAN and the NAN 🏠.
As one might imagine, there are serious security considerations in this model 🚨. Traffic between the NAN and the residential broadband network should be filtered, and the issues raised in Appendix A.1.2 take on a new level of meaning. One of the biggest threats may be a legal or at least a public relations issue. If the utility intentionally disables a circuit in a manner or at a time that threatens life (the resident's kidney dialysis machine is on it, or a respirator, for example), the matter might make the papers 📰. Unauthorized access could be part of juvenile pranks or other things as well. So one really wants the appliances to only obey commands under strict authentication/authorization controls 🔐.
In addition to the QoS issues raised in Appendix A.2, there is the possibility of queuing issues in the router. In such a case, the IP datagrams should probably use the Low-Latency Data Service Class described in [RFC4594], and let other traffic use the Standard Service Class or other service classes 🌈.
A.4. Model 3: Collector Is an IP Router 🛰️
In this third model, the relationship between the NAN and the HAN is either as in Appendix A.2 or Appendix A.3. What is different is that the collector may be an IP router. In addition to whatever autonomous activities it is doing, it forwards traffic as an IP router in some cases 💜.
Analogous to Appendix A.3, there are serious security considerations in this model 😭. Traffic being forwarded should be filtered, and the issues raised in Appendix A.1.2 take on a new level of meaning, but this time at the utility mainframe. Unauthorized access is likely similar to other financially-motivated attacks that happen in the Internet, but presumably would be coming from devices in the HAN that have been co-opted in some way. One really wants the appliances to only obey commands under strict authentication/authorization controls 🙅♀️.
In addition to the QoS issues raised in Appendix A.2, there is the possibility of queuing issues in the collector. In such a case, the IP datagrams should probably use the Low-Latency Data Service Class described in [RFC4594], and let other traffic use the Standard Service Class or other service classes 🦋.
Authors' Addresses
Fred Baker
Cisco Systems
Santa Barbara, California 93117
USA
EMail: fred@cisco.com
David Meyer
Cisco Systems
Eugene, Oregon 97403
USA
EMail: dmm@cisco.com📦 where this page comes from
- ietf: rfc6272 2011-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms