[DMM] draft-ietf-dmm-tn-aware-mobility-28 telechat Tsvart review

[Joseph Touch via Datatracker <[e-mail]>]

Document: draft-ietf-dmm-tn-aware-mobility
Title: Mobility-aware Transport Network Slicing for 5G
Reviewer: Joseph Touch
Review result: Not Ready

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
[e-mail] 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.

--