Subject: Roman Danyliw's No Objection on draft-ietf-6man-mtu-option-13: (with COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 06 Apr 2022 20:40:43 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-6man-mtu-option-13: 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-mtu-option/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you to Charlie Kaufman for the SECDIR

** Recommend consistent language on validating again off-path injection.

Both sections first make this statement:
   An upper layer protocol that validates each received
   packet discards any packet when this validation fails.

(a) Section 6.3.2.
   When packet validation fails, the upper layer MUST
   also discard the associated Option Data from the minimum Path MTU
   option without further processing.

(b) Section 8.3
   In this case,
   the host MUST also discard the associated Option Data from the
   minimum Path MTU option without further processing (Section 6.3).

Why does (b) use “host” and not “upper layer”?

** Section 1.1.  Figure 1 is a helpful summary.  Consider including another
scenario or additional text which involves a middlebox dropping the packet or
stripping the option per the behavior in Section 6.3.6 and 8.6

** Section 6.3.6
   There is evidence that some middleboxes drop packets that include
   Hop-by-Hop options.  For example, a firewall might drop a packet that
   carries an unknown extension header or option.  This practice is
   expected to decrease as an option becomes more widely used.

Is there a reference that can be used to support this optimism of middle-box
operators changing their current practice? I was under the impression that this
remains a prevalent practice and the motivation for
draft-ietf-opsec-ipv6-eh-filtering.

** Section 9.  Thank you for being explicit on the experiment goals on this
experimental document!  Would another component contributing to a successful
experiment be operators not filtering this traffic?