Thanks to Jon G. for the great SECDIR review.


* Define "NF" on the first use.

* Thanks to the authors for incorporating Jon's feedback into updates in the Security Considerations section.

# Éric Vyncke INT AD comments for draft-ietf-dmm-tn-aware-mobility-31
CC @evyncke

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

Special thanks to Satoru Matsushima for the shepherd's detailed write-up including the WG consensus *and* the justification of the intended status.

Other thanks to Carlos Bernardos, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-dmm-tn-aware-mobility-27-intdir-telechat-haddad-2026-07-06/ (and I have seen John's reply)

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## COMMENTS (non-blocking)

### Acronyms

Be sure to expand all acronyms before using them, e.g., gNB, CU, UP, ...

### Use of SVG graphics

To make a much nicer HTML rendering, suggest using the aasvg tool to generate SVG graphics. It is worth a try especially if the I-D uses the Kramdown file format ;-)

### Section 3.1

Consider adding a normative reference for `VLAN tags`.

### Section 3.3

The whole text `The source UDP port number that is encoded is the outer IP ... source port to carry slice information` is a little confusing about the use of IPsec: is it transport or tunnel mode ? Moreover is IPsec doing UDP encapsulation to traverse NAT ? A packet format would be beneficial.

Even the next paragraph is unclear whether IPsec itself is encapsulated in UDP (else with ESP the UDP ports are hidden).

### Section 4

As "VPN" is an overloaded term, please add informative references to `VPN, IP/MPLS and SR-TE`.

### Section 6

The ECMP considerations are valid but are not really about "security" and should rather be in an "operational considerations" section.

****
Wassim.Haddad@ericsson.com

Thank you for writing this document.  I note that "IP transport" in this context means transport of IP over UDP over IP, although I see only one transport-related concern;-):

## The way in which the UDP source port number is used appears to prevent the use of source port randomisation,  as recommended in [RFC8085]: a useful technique to mitigate vulnerability to off-path attack. This is expected to be acceptable use. The concern maybe was intended to be included within "To avoid spoofing..", although I'd encourage this to be explicitly stated to note this as a security consideration (perhaps cross-referencing Sect 5.1.1. of 5.1.1) and to link this to mitigations to such attack, where I see IPsec and ACLs suggested as viable possible approaches. 

### Noting the above: Should GTP-U packets set and use the IPv6 flow label as an entropy field for load balancing?

## “The source port space (~2^16) for mapping slices is more than sufficient for any realistic deployment scenario.”
- Just to be sure: Is the entire port range (2^16) really available, rather than just the ephemeral port range?

## I found it puzzling that this document speaks of IETF protocols such as UDP and a range of other terms and has no normative references! (I see I-D rev -29 updates this).
— What is the dependency upon TS.28.541-3GPP?
— I am surprised there are not normative references for the terminology used. Is all this defined here?
- I do wonder if RFC 9543 is normative background (f not, what provides the normative basis for the technologies?).

## Is a reference to UDP normative - if not, why?

## This document was reviewed as part of the transport area review team's ongoing effort to review key IETF documents. This review noted a set of concerns that have not been addressed and should be considered and the document updated.

Gorry Fairhurst
(updated comments)

Thanks to the authors and the WG for their work on this document.

I support Med's DISCUSS on the normative reference  classification. 
Several references are required to implement or safely deploy this mechanism:

- RFC 9543 defines the IETF Network Slice Service, the AC/SDP terminology
  and service characteristics used in Section 3.3, and the security
  requirements incorporated by Section 6. Moving it from normative in v29
  to informative in v31 is a regression.
- draft-ietf-dmm-udp-tunnel-acaas-extn defines the source-port/range YANG
  augmentation on which the specified provisioning depends.
- TS 29.281 defines GTP-U UDP transport and source-port behavior that this
  document uses and constrains.
- RFC 3948 is required as it specifies the ESP-in-UDP procedure that is used
  by this document.
- RFC 8085 is normative to the extent that the document relies on its
  source-port entropy, flow-affinity, or security guidance.

I also share Med's concern on whether there has been a liaison with 3GPP to
review this work. The mechanism relies directly on 3GPP TS 28.541 and
TS 29.281 and describes how 3GPP user-plane and management functions
select and provision the source-port mapping. I am not sure whether the 
proposal was formally communicated to, or reviewed by, the relevant 3GPP 
groups. Please confirm whether a liaison statement was sent or those groups
reviewed the mechanism. If no formal review has occurred, please coordinate 
with the appropriate groups and I suggest that the responsible AD holds
this document in IESG Evaluation until then.

The remaining comments are inline in the idnits output of v31. Please look
for the <EoRv31> tag at the end to ensure that the complete review is shown.

121	   internet.  Since the 3GPP Single Network Slice Selection Assistance
122	   Information (S-NSSAI) is not visible to TNs, the source UDP [RFC768]
123	   port number of the GTP-U (or UDP encapsulated GTP) bearer is used to
124	   convey a mapping to the TN slices on each 3GPP interface (i.e., F1-U,
125	   N3, N9).  The standard ephemeral source port space assigned by IANA
126	   is sufficient for any realistic deployment scenario for mapping
127	   slices.  The number of slices is likely to be far fewer than the
128	   source port space available as each slice involves significant

<major> The Dynamic/Private/Ephemeral range is not "assigned by IANA".
RFC 6335 Section 6 defines ports 49152-65535 as Dynamic Ports and says
that they are never assigned; Section 8.1.2 says that they are set aside
for local and dynamic use. RFC 768 defines the UDP header and does not
define the ephemeral range. The Dynamic Ports range also contains 14 bits
of space before any partitioning among slices.

SUGGEST
The Dynamic Ports range, 49152-65535, is set aside for local and dynamic
use by RFC 6335. A deployment can provision values or sub-ranges from this
space for the mechanism described here.

Please add RFC 6335 as the supporting reference. Retain RFC 768 only where
the UDP header itself is being described.

485	   PEs can thus be provisioned with a policy based on the source UDP
486	   port number (and other identifiers like VLAN) to the underlying
487	   transport path and then deliver the QoS/slice resource provisioned in
488	   the TN.  The source UDP port number that is encoded is the outer IP
489	   (corresponding to GTP-U header) while the inner IP packet (UE
490	   payload) is unaltered.  The source UDP port number is encoded by the
491	   node that creates the GTP-U encapsulation and therefore, this
492	   mechanism has no impact on UDP checksum calculations.  3GPP GTP-U (or
493	   IPsec encapsulated GTP-U) payloads are encapsulated in UDP packets
494	   and this solution simply uses the outer UDP source port to carry

<major> A UDP source port is neither "the outer IP" nor part of the GTP-U
header. It is a field in the UDP header carrying the GTP-U PDU. The selected
value also participates in the UDP checksum; the relevant property is that
the encapsulating node selects the value before calculating the checksum,
so no later rewrite is needed.

SUGGEST
The slice selector is encoded in the Source Port field of the UDP header
that carries the GTP-U PDU. The encapsulated UE payload is not modified.
The encapsulating node selects the source-port value before calculating
the UDP checksum, so no post-encapsulation rewrite is required.



742	   [RFC9611]  Antony, A., Brunner, T., Klassert, S., and P. Wouters,
743	              "Internet Key Exchange Protocol Version 2 (IKEv2) Support
744	              for Per-Resource Child Security Associations (SAs)",
745	              RFC 9611, DOI 10.17487/RFC9611, July 2024,
746	              <https://www.rfc-editor.org/info/rfc9611>.

<minor> RFC 9611 is not cited in the document. Please remove the entry
unless a substantive citation was inadvertently omitted.

<EoRv31>

Hi Uma, John, Sridhar, Jeff, and Luis, 

The changes made since -26 [1] address most of the comments raised in my previous ballot [2]. Thank you.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-dmm-tn-aware-mobility-26&url2=draft-ietf-dmm-tn-aware-mobility-32&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/dmm/D8NNJXcvIHk8V1Cz-W3LwZvFT2E/