Last Call Review of draft-ietf-6man-mtu-option-12
review-ietf-6man-mtu-option-12-secdir-lc-kaufman-2022-02-03-00

Reviewer: Charlie Kaufman
Review result: Has nits (though not worth holding it up for if there are no
other problems)

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document proposed to be an *experimental* RFC proposes an IPv6 header
extension in which the path MTU is computed and returned (with the help of
intermediate routers). If universally deployed, this mechanism has the
potential to provide a more efficient and more reliable method for determining
path MTU between two nodes.

If deployed only sporadically, it provides another source of clues with respect
to path MTU and use of the information might make determination of path MTU
either more or less efficient and more or less reliable.

A security concern is that on off-path node could potentially inject
misinformation about MTU of a connection as some sort of denial of service
attack. This I-D proposes a number of potential mechanisms to mitigate such an
attack, including that if a packet is dropped by an application based on it
failing some validation test, the information in the extension should be
ignored. In practice, this might be difficult to implement because these
operations are in different network layers. In particular, section 8.3
specifies that use of TLS can mitigate such attacks, but TLS integrity checks
on data can occur only once in a large number of packets, and retroactively
ignoring packets that occurred long in the past is unrealistic. The checks done
by TCP, however, can do done in-line and would probably be effective.

When doing IPsec tunneling, the path MTU cannot be updated in the inner header
and therefore may be inaccurate. An IPsec implementation could - as with the
congestion bit - translate information from an outer header to an inner header
when decapsulating to accurately report this information. Doing so would
require adjusting the path MTU to take into account the length of the IPsec
header. Such a procedure is not described or recommended by this document, but
could be in a subsequent document if this mechanism catches on.

Found 1 nit: page 17:

"When a forged packet cause a packet..." -> "When a forged packet causes a
packet..."

--Charlie

<http://aka.ms/weboutlook>