Understanding IESG DISCUSS Points On ICMP Reflection

This article dives into the IESG DISCUSS points and responses surrounding the ICMP-Reflection proposal. This is a crucial topic for network engineers and security professionals alike, as it addresses potential vulnerabilities and security considerations associated with this technology. Let's explore the concerns raised and the measures proposed to mitigate them.

IESG DISCUSS Points and Responses

Deb Cooley's Concerns: A Deep Dive into Security Risks

Deb Cooley raised significant concerns regarding the potential for abuse and security vulnerabilities associated with the ICMP Reflection mechanism. Her main point revolved around the lack of robust mechanisms to prevent modification of both requests and responses, and the potential for creating unauthorized information channels. Cooley highlighted that any entity along the path, including the sender, recipient, or middleboxes, could potentially alter the contents of the packets, leading to misinformation or data exfiltration. This critical vulnerability could be exploited to create a false illusion of network issues or, conversely, to mask existing problems, severely hindering accurate network monitoring and troubleshooting.

To address this, Cooley pointed out that the recipient could easily misrepresent the data received, and middleboxes could modify packets in either direction, compromising the integrity of the reflected information. This lack of tamper-proof assurance raised serious questions about the reliability of the mechanism for legitimate network diagnostics. Furthermore, she highlighted the danger of endpoints including arbitrary data, thereby creating a covert channel for exfiltrating sensitive information. The limited restrictions on packet size, coupled with the allowance for arbitrary data in requests, significantly increased the risk of policy violations and data breaches.

In response to Cooley's concerns, the document was amended to include a more detailed discussion of security considerations. Specifically, it acknowledged the risk of creating false illusions and preventing detection of actual network issues. The revised text highlighted that a probed node could intentionally misrepresent received data, or the Reflect All object could be modified along the path between the probing and probed nodes. While these additions provided some clarity, the fundamental challenge of preventing unauthorized modification remained a central issue. Further bolstering the security considerations, the response also emphasized that the technology inherited security risks from related protocols like RFC4443, RFC4884, and I-D.ietf-intarea-rfc8335bis, specifically ICMPv6 vulnerabilities such as covert channels and ICMP Echo Spoofing attacks. The update noted that the current document did not introduce entirely new security risks compared to existing ICMP message types, aiming to contextualize the threat level. However, Cooley’s core concerns about data integrity and the potential for misuse persisted, necessitating ongoing scrutiny and robust mitigation strategies.

Cooley also suggested several ways forward to mitigate these risks. These included: allowing middleboxes (boundary devices) to block the exfiltration of policy-prohibited data, setting hard limits for packet size, removing the allowance for including 'arbitrary data' in the request, and adding strong wording in the Security Considerations section about potential abuse. She offered her expertise in crafting the Security Considerations section to ensure comprehensive coverage of these issues. The revisions to the document included explicit language emphasizing the ability to filter or disable Reflection, aligning network operations with existing practices for managing ICMPv6 informational and error messages. This approach allows network operators to apply similar considerations to ICMPv6 Extended Echo messages used for Reflection, such as disabling support in networks that do not respond to ICMPv6 Echo or generate ICMPv6 Time Exceeded messages, offering a degree of control over potential abuse.

Eric Vyncke's Blocking DISCUSS Points: Addressing Protocol Clarity and Security

Eric Vyncke, an INT AD, provided several blocking DISCUSS points, emphasizing the need for protocol clarity and robust security measures. He acknowledged the utility of the ICMPv6 Reflection mechanism for checking extension header drops but raised concerns that required addressing before the document could proceed. A primary point of contention was the lack of a revised I-D that fully addressed the int-dir review by Suresh Krishnan, highlighting the importance of incorporating and documenting responses to external reviews in the document itself. Vyncke’s insistence underscored the necessity of transparency and thoroughness in the IETF standards process, ensuring that all feedback is considered and appropriately incorporated.

Vyncke also critiqued the description in Section 1, arguing it incorrectly focused on sending requests to “a node” instead of “an IPv6 address,” which could be anycast or multicast. This distinction is crucial because using anycast or multicast addresses could inadvertently lead to denial-of-service (DoS) amplification attacks, a significant security risk. To address this, Vyncke stressed that the document needed to clearly specify that the destination address for Extended Echo Requests must always be a unicast address to mitigate the potential for such attacks. This change ensures that responses are only sent to a single, specific address, limiting the scope for malicious actors to amplify traffic.

Further, Vyncke challenged the relevance of RFC 3022 (which deals with IPv4 NAT) in the context of IPv6. He asserted that there are other middleboxes on the Internet beyond NAT devices, and the document should not give the impression that NAT is the primary concern in IPv6 networks. More broadly, he questioned the document’s ability to prevent modifications to reflection replies, pointing out that the document lacked robust explanations for why UDP—which is used in some traceroute implementations—cannot be used as an alternative. This concern touched upon the fundamental issue of ensuring data integrity and preventing tampering, a critical aspect of any network diagnostic tool. The responses to Vyncke's points led to significant revisions, including clarifying the use cases, refining language around middlebox behavior, and reinforcing security considerations. These changes aimed to enhance the protocol’s clarity and robustness, making it more resistant to abuse and more reliable for its intended purposes.

Vyncke also targeted specific language in Section 4, advocating for the removal of the unenforceable statement that “Middle boxes must not modify the Reflect All extension object.” Recognizing that the specification cannot impose requirements on devices that do not implement it, Vyncke argued that this statement was both unrealistic and misleading. He further sought clarification on the term “Request’s ICMP Ext. Header” in Figure 1 and questioned whether the content of the sender’s ‘object payload’ should be zeroed to prevent covert channels. In Section 5, Vyncke highlighted inconsistencies and ambiguities regarding the handling of multiple objects and C-Type field values, which prompted revisions to ensure that the ‘Reflect All’ object must be the only object in the Extension Structure and that unsupported C-Type values result in message discarding to prevent looping attacks. Additionally, he questioned why the object payload field in a request message should not be required to be all zeros, arguing that allowing other data could open doors for covert channels. This point sparked considerable discussion, ultimately leading to a change in the text to state that the object payload field in a request message contains arbitrary data, a decision that was carefully weighed against the potential security implications.

Suresh Krishnan's INT-DIR Review: Focusing on Middlebox Behavior and Specification Clarity

Suresh Krishnan, the Internet Directorate reviewer, raised several important points, primarily focusing on the behavior of middleboxes and the clarity of certain specifications. One of his major concerns centered around the statement in Section 4 that “Middle boxes must not modify the Reflect All extension object.” Krishnan questioned the utility and enforceability of this requirement, especially given that a rationale for the new mechanism was the potential modification of ICMPv6 messages by middleboxes. This point underscored a fundamental tension in the document: how to ensure the integrity of the reflection mechanism when middleboxes, which are not bound by the specification, could potentially interfere. The review emphasized the need for realistic expectations about network behavior and the limitations of imposing requirements on unaudited devices.

Krishnan also highlighted a statement in Section 1 suggesting that middleboxes modify the invoking packet in ICMPv6 Destination Unreachable messages, citing RFC 3022. He questioned whether this behavior had been empirically observed and suggested that a more appropriate citation might be needed. The idea of IPv6 middleboxes altering packet contents sparked concern, prompting a revision of the text to ensure accuracy and relevance. This focus on empirical evidence and precise citations reflects the IETF’s commitment to basing standards on real-world experience and avoiding speculative claims. Additionally, Krishnan pointed out that the document should simply refer to RFC 8200 for the IPv6 minimum MTU (1280 bytes) rather than repeating the number, promoting consistency and reducing redundancy in the specification. In Section 5, he questioned the purpose of the text describing the object payload field, suggesting that the sentence “this field MAY contain arbitrary data” was sufficient to cover the case where the field may contain all zeros, advocating for concise and unambiguous language.

Gorry Fairhurst's DISCUSS Points: Rate Limiting, Hop Limit, and Extension Headers

Gorry Fairhurst’s DISCUSS points centered on several technical aspects of the ICMPv6 Reflection mechanism, focusing on rate limiting, hop limit behavior, and the handling of extension headers. Fairhurst first questioned the document’s assertion that it “SHOULD rate-limit incoming ICMP Extended Echo Request messages,” noting that RFC 4443 requires “an IPv6 node MUST limit the rate of ICMPv6 error messages it originates.” This comparison highlighted a potential inconsistency in the level of requirement, prompting a discussion on whether the current wording adequately conveyed the importance of rate limiting to prevent abuse. The response clarified that the rate-limiting requirement was defined in RFC 8335 (and RFC 8335bis), aligning the current draft with existing standards and emphasizing the continuity of the requirement.

Another critical point raised by Fairhurst concerned the hop limit field in the returned packet header. He asked whether the value would be decremented during receiver packet processing at the probed node or if it would retain the value as received. Understanding the hop limit behavior is crucial for diagnostic purposes, as it provides insights into the path traversed by the packet. The response clarified that, as defined in RFC 8335bis, the hop limit in the ICMPv6 Extended Echo Reply message MUST be set to 255, ensuring that the reply has a sufficient hop count to reach the originator without being prematurely discarded. This standardization simplifies the interpretation of hop limit values and enhances the utility of the reflection mechanism for path analysis.

Fairhurst also questioned whether received Extension Headers (EHs) are included in the returned packet header, specifically asking if the EH Chain is present in the returned packet header. This point is vital for understanding how the reflection mechanism interacts with IPv6 extension headers, which are used to carry additional information and options. The response indicated that the inclusion of EHs depends on the probed node’s policy and is not restricted by the current document. This flexibility allows network operators to tailor the reflection behavior to their specific needs and security policies but also introduces variability that must be considered when interpreting reflection results.

Ketan Talaulikar's Concerns: OAM Purpose, Middlebox References, and Message Size Checks

Ketan Talaulikar raised several significant issues, primarily concerning the purpose of the extension, references to middleboxes, the strictness of message size checks, and other protocol nuances. Talaulikar questioned whether the document’s main goal was solely for Operations, Administration, and Maintenance (OAM) purposes, specifically to determine how IPv6 headers and extension headers are processed during network transit. If this was the case, he wondered why the document included extensive discussions and references to middleboxes. Talaulikar argued that these references might be superfluous and detract from the document’s core focus, suggesting that removing them would clarify the document's purpose.

He reasoned that if middleboxes were performing security checks, they might simply block the new mechanism once it is published, making any attempt to circumvent them futile. This perspective challenged the document’s implicit assumption that the reflection mechanism could be used to bypass middlebox policies, asserting that a more direct and transparent approach might be more effective. Talaulikar’s concerns prompted a significant revision of the use case section, aiming to better clarify the potential applications of the mechanism and to more accurately frame its role in network diagnostics. The revised text emphasized that the tool is purpose-built for monitoring how packets are affected along a network path, enabling operators to adapt policy controls on the nodes along the path for it. This clarification sought to address Talaulikar’s skepticism by highlighting the proactive aspects of the mechanism in network management.

Talaulikar also expressed confusion over the strict message size checks against the allowed payload size in the Reflect-All object. He asked what would happen if the extension header size were to change or if some extension headers were inserted or removed in transit, regardless of whether such changes are permitted by RFC 8200. Talaulikar argued that the strict size check would prevent the detection of such changes, as only an error would be reported, rather than detailed information about the modifications. To address this, Talaulikar suggested allowing the Reflect-All object to carry sufficient space for the exact originated payload but permitting the responder to include as much information as needed to carry the payload in the response. This approach would enable more comprehensive detection of packet alterations, enhancing the diagnostic utility of the mechanism.

Further concerns included the handling of larger padded packet sizes for MTU checks and the need for clarity on how the probed node should respond under various conditions. Talaulikar noted that the specification presented a limited view of potential responses, suggesting that simply dropping the packet might be a more appropriate action in certain scenarios, such as when rate-limiting policies are triggered or when local policies prohibit reflection. In response, the sentence prescribing actions under certain conditions was removed, and the text was revised to indicate that the probed node formats an ICMPv6 Extended Echo Reply message provided that this action aligns with its local policies, such as security policies and rate limiting. This change provided greater flexibility in implementation and allowed nodes to adhere to their operational constraints.

Mike Bishop's Fundamental Concerns: Middlebox Compliance and Potential Abuse

Mike Bishop's primary concerns revolved around middlebox compliance and the potential for abuse. He critiqued the draft’s assertions regarding middlebox behavior, pointing out the impracticality of imposing requirements on devices that do not implement the specification. Bishop argued that statements such as