[IPv6]John Scudder's No Objection on draft-ietf-6man-hbh-processing-17: (with COMMENT)

John Scudder via Datatracker <noreply@ietf.org> Sun, 26 May 2024 18:50 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 10F23C14F5E9; Sun, 26 May 2024 11:50:36 -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: <171674943605.43268.7653957015845054003@ietfa.amsl.com>
Date: Sun, 26 May 2024 11:50:36 -0700
Message-ID-Hash: DCMQTYZQUZDBEHYWY7VAEV3KH57TZGT6
X-Message-ID-Hash: DCMQTYZQUZDBEHYWY7VAEV3KH57TZGT6
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/wEPGAWWG6-BO3dmvAxOFiN9ew68>
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:
----------------------------------------------------------------------

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/.