[DMM] Ketan Talaulikar's No Objection on draft-ietf-dmm-tn-a ware-mobility-31: (with COMMENT)

Ketan Talaulikar has entered the following ballot position for
draft-ietf-dmm-tn-aware-mobility-31: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-tn-aware-mobility/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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>



_______________________________________________
dmm mailing list -- [email protected]
To unsubscribe send an email to [email protected]