This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

This document was reviewed solely from a transport perspective. It does not address the viability of this mechanism nor its intended utility.

The key transport issues appear to be as listed below. Items A and B can be resolved by simple edits. Item C requires more extensive revision to address. Item D appears to be unresolvable, given this is intended as an informational RFC and intends to override a standards-track RFC.

Joe

A. Use of UDP source ports for packet identification
    o	There is nothing inherently problematic about this, 
        as long as these ports are understood not to be assigned 
        or reserved, and to notably avoid the potentially hazardous
        use of the “0” port value, which can trigger unexpected behavior 
        in some systems.
B.	Referring incorrectly to “IP source ports” in numerous places
    o	Transport layers have ports, not IP packets
    o	If this refers to the UDP source port, it would be useful to 
        correct the terminology and more clearly explain the header 
        sequence expected
C. Conflicts with RFC3948
    o	RFC 3948 requires that UDP-encapsulated ESP “MUST” use the 
        same source and destination ports as that used by IKE traffic 
        (in that RFC, Sec 2.1)
    o	This document appears to intend to override that rule such 
        that source ports are configurable (this doc, Sec 6, paragraph 4).
    o	As an informational document, this document cannot override 
        RFC 3498, nor does it currently appear to correctly (it would 
        require an “updates” marking).
D. Lack of discussion of path MTU and fragmentation concerns
    o	The document makes liberal use of UDP encapsulation, 
        but never mentions any issues with increased overheads, 
        packet loss, computational effort, required storage, or 
        security implications involved with IP fragmentation and 
        reassembly, nor any discussion of interaction with PLPMTUD.
    o	The key security implication is the increased potential 
        for DOS attacks at the reassembly points, and this should be 
        included in the security considerations.
    o	In particular, IP fragmentation MUST occur in the encapsulated 
        IP outer packet, not by fragmenting the inner IP packet 
        because the potential for on-path fragmentation cannot be 
        assumed (the inner IP packet could be IPv4 with DF=0 or IPv6,
        neither of which can be fragmented on-path).
    o	New UDP options do support UDP-layer fragmentation (RFC 9868) 
        and could be included in this discussion, but these are not 
        yet widely deployed.

--