ICMP Extensions for Environmental Information

Abstract

This document defines a data structure that can be appended to selected ICMP messages. The ICMP extension defined herein can be used to gain visibility on environmental impact information on the Internet by providing per-hop (i.e., per topological network node) power metrics and other current or future sustainability metrics. This will contribute to achieving an objective mentioned in the IAB E-Impact workshop.¶

The techniques presented are useful not only in a transactional setting (e.g., a user-issued traceroute or a ping request), but also in a scheduled automated setting where they may be run periodically in a mesh across an administrative domain to map out environmental-impact metrics.¶

2. Conventions

4. Transport Options for Sustainability Information

To achieve the goal of transporting useful sustainability information across the network, there are two key considerations. First, what information is useful to convey and in what format, and second, how to transport that sustainability information.¶

For the first task, it is critical to normalize and agree upon the information to convey and format, across potentially multiple transports.¶

For the second task, there is a variety of options available depending on use cases. These can be categorized based on whether the approach is distributed (i.e., any endpoint or node can request and/or receive the sustainability information) or centralized (i.e., a single 'controller' compiles and consolidates the information.) They can also be categorized based on the networking layer used (e.g., IP, like ICMP, or application, like SNMP). Further, an existing protocol can be extended, or a brand new protocol can potentially be created for this purpose.¶

This document builds upon a standardized, modular, backwards-compatible, and scale-proven ICMP extension [RFC4884]. This does not preclude the definition of other methods to transport sustainability information, more fitting to other use-cases.¶

5. ICMP Environmental Information Extension

This section defines the Environmental Information Object, an ICMP extension object with a Class-Num (Object Class Value) of TBA that can be appended to the following messages, as per [RFC4884] and [RFC8335]:¶

• ICMPv4 Time Exceeded¶

• ICMPv4 Destination Unreachable¶

• ICMPv4 Parameter Problem¶

• ICMPv4 Extended Echo Reply [RFC8335]¶

• ICMPv6 Time Exceeded¶

• ICMPv6 Destination Unreachable¶

• ICMPv6 Extended Echo Reply [RFC8335]¶

The ICMP extension defined in this document MAY be appended to any of the above listed messages based on policy and following security considerations.¶

These extensions are preceded by an ICMP Extension Structure Header, and include an ICMP Object Header. Both are defined in [RFC4884]. The same backward compatibility issues that apply to [RFC4884] apply to this extension.¶

A single ICMP message can contain zero, one, or multiple instances of Environmental Information Objects. The C-Type further identifies the information fields carried.¶

A single instance of the Environmental Information Object can convey one of the information elements defined in Section 5.2 from each reporting node in an administrative domain.¶

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
|Version|       Reserved        |           Checksum            |(1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
|             Length            |   Class-Num   |   C-Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+(2)
~                        Object payload                         ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...

                     1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Length            | Class-Num=TBA | C-Type=1-255  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6. Sample Use Case

This section explains a typical use case of the extensions.¶

7. Security Considerations

The security considerations of [RFC4884] and of [RFC8335] apply to these extensions.¶

Upon receipt of an ICMP message, application software must check it for syntactic correctness. The extension checksum MUST be verified. Care should be taken, as improperly specified length attributes and other syntax problems may result in buffer overruns.¶

This document does not define the conditions under which a router sends an ICMP message. Therefore, it does not expose routers to any new denial-of-service attacks. Routers may need to limit the rate at which ICMP messages are sent.¶

This document defines an extension that allows a router to append environmental impact information to multi-part ICMP messages in a single administrative domain, and therefore can provide the user of the traceroute and ping applications with additional metrics.¶

The intended field of use for the extensions defined in this document is administrative debugging and troubleshooting and operational facilities. The extensions herein defined supply additional information in ICMP responses. These mechanisms are not initially intended for other uses.¶

Some of the additional metrics provided, as e.g., power draw information, have privacy considerations. For example, behavioral considerations of the devices, or estimating other node and network attributes from the power or energy data. Other things like identification of the node, deducing node usage patterns are some more privacy concerns that can be related to the metrics.¶

Keeping these considerations in mind, we limited the scope of the transportation of the sustainability metrics to a single administrative domain. But, based on [RFC8799], limiting a protocols functionality doesn't mean that it will be secure. So, this particular document, which defines "a modified ICMP message with sustainability metrics", can be classified as a FAIL-OPEN protocol [I-D.wkumari-intarea-safe-limited-domains]. That is, the interfaces of administrative domain border nodes, facing towards the open internet, can be configured such that they avoid leaking messages with extensions containing sustainability metrics, out of the AD. To allow general ICMP messages, an administrator can configure those outward facing interfaces to not block/drop the entire message but only strip off the extension objects and only forward the ICMP message if it is destined to go out of the AD.¶

When metrics are limited to the same AD, it can be considered that they can be generated from a valid source and will have integrity.¶

This document does not specify an authentication mechanism for the extension that it defines. Application developers should be aware of various ICMP attacks [RFC5927].¶

8. IANA Considerations

IANA is requested to assign the following object Class-num in the ICMP Extension Object Classes and Class Sub-types registry [IANA-ICMP-Extended]:¶

IANA is requested to establish a registry for the corresponding class sub-type (C-Type) space, as follows:¶

C-Type values are assignable on a first-come-first-serve (FCFS) basis.¶

IANA is requested to establish a registry for Ecolabels and Environmentally Relevant Certification (EERC) numbers (C-Type 2), as follows:¶

EERC numbers are assignable on a first-come-first-serve (FCFS) basis.¶

9. Acknowledgements

We are very grateful to Jari Arkko for his thorough review and most useful set of comments and suggestions.¶

10. References