[IPv6]John Scudder's No Objection on draft-ietf-6man-hbh-processing-17: (with COMMENT)
John Scudder via Datatracker <noreply@ietf.org> Tue, 28 May 2024 21:31 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A858C14CE45; Tue, 28 May 2024 14:31:06 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.13.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171693186655.53507.4864036631408497005@ietfa.amsl.com>
Date: Tue, 28 May 2024 14:31:06 -0700
Message-ID-Hash: E5ELBEGDSRJB7MVI5EXNYYUBPV3LRCSC
X-Message-ID-Hash: E5ELBEGDSRJB7MVI5EXNYYUBPV3LRCSC
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ipv6.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-6man-hbh-processing@ietf.org, 6man-chairs@ietf.org, ipv6@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: John Scudder <jgs@juniper.net>
Subject: [IPv6]John Scudder's No Objection on draft-ietf-6man-hbh-processing-17: (with COMMENT)
List-Id: "IPv6 Maintenance Working Group (6man)" <ipv6.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/GytsCK2vHrPz7MiNOYwSocPh_ew>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Owner: <mailto:ipv6-owner@ietf.org>
List-Post: <mailto:ipv6@ietf.org>
List-Subscribe: <mailto:ipv6-join@ietf.org>
List-Unsubscribe: <mailto:ipv6-leave@ietf.org>
John Scudder has entered the following ballot position for draft-ietf-6man-hbh-processing-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-hbh-processing/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (I realized I had forgotten to capture one point while transcribing my notes. This updated ballot adds one more point, right at the end.) This document uses a lot of words to say what is ultimately a fairly simple message. It's also an important message, so I think it's worth the time to communicate it clearly; hence the effort put into this review. (The quote attributed to Pascal, to the effect of "I am sorry I have written you a long letter, I did not have time to write you a short one" might apply here.) As far as I can tell, the spec's TL;DR is: Routers: - SHOULD process HbH options as long as they can do so without compromising forwarding rate. - If it would compromise forwarding rate, they should triage the HbH options they process. (Details of triage not specified other than letting the operator configure HbH options to respect/ignore.) - Can ignore the whole HbH header by default, or can process it but use configuration to control what individual HbH options are processed. - MUST NOT drop a packet just because it contains a HbH header. - SHOULD make the list of HbH options that are processed configurable. - Concerning the RA option, if processing it at all, - "MUST protect itself from infrastructure attack". - Shouldn't bother the control plane for an RA that has no Value field of interest. Hosts when receiving: - SHOULD process HbH headers, and process all options within - But may choose not to process them (e.g. constrained hosts) - For any HbH header not processed, they MUST (Section 5.1) behave as if it wasn't present. Hosts when sending: - SHOULD "use a method that is robust". - MAY include more than one HbH option. I feel fairly strongly that this document would be more valuable if it were less expository, more prescriptive, and shorter -- "crisper", if you like. However, my concerns don't rise to the level of blocking publication, so I've captured some specific and potentially actionable points in comments, and I understand that the authors' preferences may not be the same as mine, or that they may not have the appetite for a large rewrite. On the other hand, if you're up for the challenge, I'm willing to contribute more effort. Note that not all of my comments are of that nature, many relate to correctness and accuracy -- so even if you completely disagree with my editorial point of view, please look over the rest of them. ## COMMENT ### Section 3, cut-and-paste error? * control plane: IPv6 routers exchange control information through the control plane. This processes the management and routing information exchanged with other routers. So far so good. Routers process fields contained in packet headers. However, they do not process information contained in packet payloads. This sentence is a verbatim copy of a sentence in the definition of "forwarding plane". Is it a cut-and-paste error? It doesn't seem relevant to a definition of the control plane. ### Section 4, rewrite for clarity, add informative reference The pronouns and determiners in the last couple of paragraphs make it hard to nail down what they mean. I think a simple rewrite to add more specificity would help. Assuming I've understood your meaning correctly, something like this, OLD: "Transmission and Processing of IPv6 Extension Headers" [RFC7045] clarified how intermediate nodes should process Extension Headers. This document is generally consistent with [RFC7045], and was raised as an issue for discussion when [RFC2460] was updated and replaced by [RFC8200]. This document updates [RFC8200] as described in the next section and consequently clarifies the description in Section 2.2 of [RFC7045], using the language of BCP 14 [RFC2119] [RFC8174]. The document defines a set of procedures for the Hop-by-Hop Options header that are intended to make the processing of Hop-by-Hop options practical in modern transit routers. The common cases are that some Hop-by-Hop options will be processed across the Internet, while others will only be processed within a limited domain [RFC8799] (e.g., where a specific service is made available in that network segment that relies on one or more Hop-by-Hop options). NEW: "Transmission and Processing of IPv6 Extension Headers" [RFC7045] clarified how intermediate nodes should process Extension Headers. The present document is generally consistent with [RFC7045], and addresses an issue that was raised for discussion when [RFC2460] was updated and replaced by [RFC8200]. This document updates [RFC8200] as described in the next section and consequently clarifies the description in Section 2.2 of [RFC7045], using the language of BCP 14 [RFC2119] [RFC8174]. This document defines a set of procedures for the Hop-by-Hop Options header that are intended to make the processing of Hop-by-Hop options practical in modern transit routers. The common cases are that some Hop-by-Hop options will be processed across the Internet, while others will only be processed within a limited domain [RFC8799] (e.g., where a specific service is made available in that network segment that relies on one or more Hop-by-Hop options). Since you allude to "an issue that was raised for discussion", it also wouldn't go amiss to provide an informative citation to the relevant list thread. ### Section 5.1, use the RFC 8200 words Suggested rewording, both for correctness and to use the language of RFC 8200: OLD: [RFC8200] also requires that a Hop-by-Hop Options header only appear once in a packet. NEW: [RFC8200] also requires that a Hop-by-Hop Options header appear at most once in a packet. ### Sections 5.1, 5.1.1, clarity You juxtapose a quote from RFC 8200 that says (my paraphrase, with BCP 14 keyword added to be provocative) "routers SHOULD NOT process the HbH header unless explicitly configured to do so", next to a new requirement that "clarifies that a configuration could control whether processing skips any specific" HbH option. I'll paraphrase that one too, again inserting a BCP 14 keyword, as "routers MAY instead process the HbH header by default while allowing configuration to disable specific options." I guess those two things are compatible, but I had to do too much work to extract that interpretation and I'm not even confident that's really what you're trying to say. Can you confirm that it is? As a follow-up, if my paraphrase is right, how do you reconcile Section 5.1 where you say "Routers SHOULD process the Hop-by-Hop Options header" with (my paraphrase of) RFC 8200? You might reply that I've changed the meaning of Section 5.1 by omitting "using the method defined in this document", but if so I think you should rephrase the Section 5.1 language for clarity, as in, OLD: Routers SHOULD process the Hop-by-Hop Options header using the method defined in this document NEW: Routers that process the Hop-by-Hop Options header SHOULD do so using the method defined in this document. On the other hand, if you intend that "Routers SHOULD process the Hop-by-Hop Options header", I think you have more work to do in Section 5.1.1, as discussed above. ### Section 5.2, first HbH option The first couple of paragraphs appear to privilege the first HbH option compared to the rest. Is this deliberate? Can you help me understand why, if so? For example, A router configuration needs to avoid vulnerabilities that arise when it cannot process the first Hop-by-Hop option at full forwarding rate. A router SHOULD NOT therefore be configured to process the first Hop-by-Hop option if this adversely impacts the aggregate forwarding rate. A router SHOULD process additional Hop-by-Hop options, if configured to do so, providing that these also do not adversely impact the aggregate forwarding rate. When I unpack this, how is it different from (my text): A router configuration needs to avoid vulnerabilities that arise when processing of a Hop-by-Hop option would prevent it from forwarding at full forwarding rate. A router SHOULD process Hop-by-Hop options, if configured to do so, providing that these do not adversely impact the aggregate forwarding rate. The primary change in my rewrite was to cut A router SHOULD NOT therefore be configured to process the first Hop-by-Hop option if this adversely impacts the aggregate forwarding rate. As far as I can tell the rewrite is semantically the same, but I'm concerned that I have missed something, otherwise, why would you have put in that special mention of the first option? :-( One interpretation I came up with after reading it a few times is that what you mean is something like "when it cannot process even a single Hop-by-Hop option at full forwarding rate". Does that get at your intent? I appreciate that practically speaking, most forwarding code will go through the options serially starting with the first, but not only is that not a requirement, but in some of your other text you drive home the message that the order of processing is not guaranteed. So, I think you should be careful to separate that assumption from what you're trying to specify. This is only one example. Another is the first paragraph, A source creating packets with a Hop-by-Hop Options header SHOULD use a method that is robust to network nodes processing only the first Hop-by-Hop option that is included in the packet, or that forward packets without the option being processed (see Section 6.1). I would've expected something more like, A source creating packets with a Hop-by-Hop Options header SHOULD use a method that is robust to network nodes selectively processing only some of the Hop-by-Hop options that are included in the packet, or that forward packets without the option(s) being processed (see Section 6.1). As it is, a close reading of the sentence tells me it's fine if the method is *not* robust to network nodes that process only the second option, for example. This isn't a full scrub of the section, e.g. the fourth paragraph has "further" (after what? The first? The last one successfully processed?) ### Section 5.2, including more than one HbH option I found "A source MAY, based on local configuration, include more than one Hop-by-Hop option" peculiar, given that there's never been a restriction on that in the past (has there?), i.e. you're granting permission for something that was always allowed, so... thanks? I think I see what you're doing, which is to subtly throw shade on the idea of including more than one HbH option, but if you want to do that, why do it subtly? E.g., you could go whole hog with something like A source SHOULD NOT include more than one Hop-by-Hop option, although it MAY do so based on local configuration. In the latter case it might wish to restrict the size... ### Section 5.2, clarity OLD: If a router is unable to process any Hop-by-Hop option (or is not NEW: If a router is unable to process a given Hop-by-Hop option (or is not ### Section 5.2, sense of "any" is underdetermined This document modifies this behaviour for the "01", "10", and "11" action bits, so that if a router is unable to process any Hop-by-Hop option (or is not configured to do so), it SHOULD behave in the way specified for an unrecognized Option Type when the action bits were set to "00". It also modifies the behaviour for the "10" and "11" Is "any Hop-by-Hop option" supposed to mean "any given HbH option" or is it supposed to mean "no HbH option"? I think it's the former, in which case, I suggest the change. ### Section 5.2, clarity, standalone patch This document modifies this behaviour for the "01", "10", and "11" action bits, so that if a router is unable to process any Hop-by-Hop option (or is not configured to do so), it SHOULD behave in the way specified for an unrecognized Option Type when the action bits were set to "00". ... The modified text for "01", "10", and "11" values is: 01 - MAY discard the packet. Nodes should not rely on routers dropping these unrecognized Option Types. 10 - MAY discard the packet ... 11 - MAY discard the packet ... And as a reminder (to me, at least!), 00 is: 00 - skip over this option and continue processing the header. I had to go over this several times before I finally worked out that the modified text for the three values quoted above is not actually in conflict with the SHOULD in the first quoted paragraph. While puzzling over it, I also noticed that even though all three values are modified to permit discard, only the first includes the sentence "Nodes should not rely on routers dropping these unrecognized Option Types". It seems to me that even though it would make the document more verbose, and isn't strictly mandatory for technical correctness upon careful reading, it would be helpful for clarity to spell things out more explicitly, as in, NEW: The modified text for "01", "10", and "11" values is: 01 - SHOULD behave as specified for 00, but MAY discard the packet if so configured. 10 - SHOULD behave as specified for 00, but MAY discard the packet if so configured and, regardless of whether or not the packet's Destination Address was a multicast address, and if the packet was discarded, MAY send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. 11 - SHOULD behave as specified for 00, but MAY discard the packet if so configured and, only if the packet's Destination Address was not a multicast address, and the packet was discarded, MAY send an ICMP Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. Nodes should not rely on routers dropping unrecognized Option Types. I added a SHOULD clause for each. I also added "if so configured" to the MAY parts, it's unclear to me if that's overreach or helpful clarification of intent since I don't know if you intended the MAY to cover other cases too. Finally, I factored out the "should not rely on" sentence so that it doesn't appear to apply only to the 01 case. Apart from simple readability, the other argument I'd give in favor of making this change (or one like it) is that in this kind of patch-type approach to updating a base document (which is what this is, despite the fact you haven't used OLD/NEW blocks), it's desirable for the patched base document to at least potentially stand alone. ### Section 5.2, "a multicast address", plus RFC 2119 keyword I have two concerns about When a node sends an ICMP message in response to a packet with a multicast address, this could be exploited as an amplification attack. This is particularly problematic when the Source Address is not valid (which can be mitigated to varying degrees by using a reverse path forwarding (RPF) check). A node SHOULD only send ICMP messages in response to a packet with a multicast address when this is enabled for the specific Source Address and/or the group Destination Address. The first concern is that when you write "a packet with a multicast address", it's not clear, until one reads the final sentence, that you mean either the source address or the destination address. I suggest spelling it out explicitly. The second concern is that although your intent with "SHOULD only" is clear enough, it doesn't fit the RFC 2119 definition of SHOULD. A possible rewrite to cover both concerns is, NEW: When a node sends an ICMP message in response to a packet with a multicast source or destination address, this could be exploited as an amplification attack. This is particularly problematic when the Source Address is not valid (which can be mitigated to varying degrees by using a reverse path forwarding (RPF) check). A node SHOULD NOT send ICMP messages in response to a packet with a multicast source or destination address unless this is enabled for the specific Source Address and/or the group Destination Address. (You could use "and/or" wherever I have put "or", but in my view it's not necessary, after all, it's not "xor".) ### Section 5.2, expository paragraph needed? Is this paragraph doing any necessary work? When an ICMP Parameter Problem, Code 2, message is delivered to the source, the source can become aware that at least one node on the path has failed to recognize the option. Generating an ICMP message incurs additional router processing. Reception of this message is not guaranteed, routers might be unable to be configured so that they do not generate these messages, and they are not always forwarded to the source. The motivation here is to loosen the requirement to send an ICMPv6 Parameter Problem message when a router forwards a packet without processing the list of all options. I can see how it might've been needed during working group development of the document, but if I imagine I'm an implementor reading this spec, I'm not sure what I do with it. As far as I can tell the whole thing can be condensed down to "you might not get an IMCP parameter problem if one of your options isn't recognized, but then again that was always true"... and because of "that was always true", you could leave it out without harm. ### Section 5.2.1 The function of a Router Alert Option can result in the processing that this specification is proposing to eliminate, that is, to instruct a router to process the packet in the control plane. I don't think this specification is solely proposing to protect the control plane, it's also trying to protect the forwarding plane from option lists that are too heavyweight to be processed at line rate in the fast path. (Bullets 3 and 4 in the second bullet list in Section 4.) Fortunately, a rewrite to correct this is as simple as removing one definite article. NEW: The function of a Router Alert Option can result in processing that this specification is proposing to eliminate, that is, to instruct a router to process the packet in the control plane. ### Section 5.2.2, inappropriate RFC 2119 keyword The final paragraph of this section is the single sentence, The actions of the lookup table SHOULD be configurable by the operator of the router. But the previous paragraph told me that said lookup table is "a possible approach". It seems weird to me to use an RFC 2119 keyword to mandate behavior specific to "a possible approach". If I were you, I'd use lowercase "should", and I would combine this paragraph with the preceding one. ### Section 6, "simple to process" isn't actionable * New Hop-by-Hop options SHOULD be designed to ensure the router can process the options at the full forwarding rate. That is, they should be simple to process (see Section 5.2). I don't see anything in Section 5.2 that tells me how to make an option simple to process. If you think it does explain that, please help me understand how. Otherwise, I think you should remove the cross-reference. For that matter, even with the suggested change, this bullet point makes me a little bit sad because it feels isomorphic to the famous "don't write bugs" advice. (See also RFC 9225.) But, ¯\_(ツ)_/¯ ### Section 8, forcing packets to the slow path can also harm the control plane Security issues with including IPv6 Hop-by-Hop options are well known and have been documented in several places, including [RFC6398], [RFC6192], [RFC7045] and [RFC9098]. The main issue, as noted in Section 4, is that any mechanism that can be used to force packets into the router's control plane can be exploited as a Denial-of- Service attack on a transit router by saturating the resources needed for router management (routing protocols, network management protocols, etc.) and cause the router to fail or perform sub- optimally. There is a related but not identical issue, which is that in many routers, some resources are shared between the control plane and the slow path -- you nod to this in your definition of "slow path" in Section 3. Even if packets are forced only into the slow path, but not the control plane, that can still work as a denial of service attack against the control plane. I suppose we might get into an ontological debate about what exactly "the control plane" is in this context and whether the paragraph as written already encompasses it, but I think it would be better to err on the side of completeness even if it requires a bit more verbosity. The fix I propose is simple enough, though: s/control plane/slow path or control plane/. ### Section 8, misleading bullet points I think these two bullet points are misleading in a couple of ways: * The document sets an expectation that if a packet includes a single Hop-by-Hop option that packet will be forwarded across the network path." * Additional Hop-by-Hop options MAY be included, based on local configuration. Nodes only process these additional Hop-by-Hop options if configured to do so. The first bullet, by focusing on "a single Hop-by-Hop option", implies that if multiple options were included, the packet might not be forwarded. I think that's not right, per my understanding of the document. The second bullet's second sentence ("only process... if") appears to be a case of "the exception proves the rule" that nodes commit to processing the first Hop-by-Hop option. But this is also not right. For that matter, it's not clear whether "nodes" in that sentence refers to destination or intermediate nodes. I have assumed the latter. A rewrite might be, NEW: * The document sets an expectation that if a packet includes a Hop-by-Hop Options header that packet will be forwarded across the network path. * A source MAY include one or more Hop-by-Hop options. Whether any of these options is processed, and if so which and how many, is dependent on the configuration of intermediate nodes.
- [IPv6]John Scudder's No Objection on draft-ietf-6… John Scudder via Datatracker