Subject: Paul Wouters' No Objection on draft-ietf-6man-mtu-option-13: (with COMMENT)

From: Paul Wouters via Datatracker <[email-masked]>
Date: Thu, 07 Apr 2022 06:13:36 -0700

Paul Wouters 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:
----------------------------------------------------------------------

While experimentation is good, I also share the concerns voiced by Bernard
Aboba
(https://datatracker.ietf.org/doc/review-ietf-6man-mtu-option-13-artart-lc-aboba-2022-03-09/)
that this experiment repeats the failure of RFC 1063

   If the MTU of the link is less than the Min-PMTU,
   it rewrites the value in the option data with the smaller value.

Wouldn't this mean that what is stored is the maximum path mtu, not the minimum
one?

It would be good to mention IPsec (both ESP transport mode whether the option
is not (?) expected to work, and for ESP tunnel mode, where the option in the
encapsulated packet could set to take into account the IPsec overhead for both
ESP and possible ESPinUDP. Or the outer ESP packet could set the option after
some header calculations.

    The use of this option with DNS and DNSSEC over UDP

DNS already has its application layer options to deal with MTU via an EDNS
option. Although it could possibly read value from the network packet and use
that in its ENDS option answer, it is not sure if this is worth the risk of
abuse, where amplification attacks are common. If this experiment is not widely
deployed, it could mean that excessive large values would actually make it to
the DNS server, so using those values could be damaging especially if the
packet was spoofed and the large packets are returned to the real victim.

I am not sure how TLS or IPsec could protect this option, as it is required to
be modified on-path ?

  When a forged packet causes a packet to be sent including the minimum
   Path MTU option, and the return path does not forward packets with
   this option, the packet will be dropped Section 6.3.6.  This attack
   is mitigated [...]

Isn't dropping the spoofed packet mitigation enough?