Hi Joe, all,
The authors have revised the draft (rev 29) to address the comments A - D.
Some short notes on the revision:
A: added text to clarify re: reserved or "0" value port + other recommended
revisions (see Diff attached below).
B: revised instances of "IP source ports" to "UDP source ports"
3GPP specifies the protocol encapsulations and we have referred to them.
No changes to any of those encapsulations are made here.
C: Revised text to state that for many 5G inter and intra-domain cases there
are no NATs in between the SEGs.
In scenarios where NATs may be present (e.g., MVNOs), the draft now states
that RFC3948 mandates port 4500 and since these procedures require port
diversity, it cannot be used.
Ongoing work in IETF such as [draft-xu-ipsecme-esp-in-udp-lb] and
[draft-antony-ipsecme-udp-encap-multiport] can hopefully address that in the
future.
D: This draft makes no additions to the encapsulations that exist in current
3GPP procedures (with GTP-U / UDP) - only reuses UDP source port.
3GPP has mechanisms to specify how to handle fragmentation with GTP
tunneling (i.e., PCO - Protocol Configuration Options that specify MTU, etc.)
Added text to clarify that the 3GPP mechanisms should continue to be used.
Links:
URL:
https://www.ietf.org/archive/id/draft-ietf-dmm-tn-aware-mobility-29.txt
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmm-tn-aware-mobility-29
Best Regards,
John
> -----Original Message-----
> From: Joseph Touch via Datatracker <[email protected]>
> Sent: Thursday, July 23, 2026 12:38 AM
> To: [email protected]
> Cc: [email protected]; [email protected]; last-
> [email protected]
> Subject: draft-ietf-dmm-tn-aware-mobility-28 telechat Tsvart review
>
> 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 tsv-
> [email protected] 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.
>
> --
>
_______________________________________________
dmm mailing list -- [email protected]
To unsubscribe send an email to [email protected]
