IETF Last Call Review of draft-ietf-dmm-tn-aware-mobility-26
review-ietf-dmm-tn-aware-mobility-26-secdir-lc-geater-2026-07-01-00

# SECDIR Review: draft-ietf-dmm-tn-aware-mobility-26

**Document:** Mobility-aware Transport Network Slicing for 5G
**Reviewer:** [your name]
**Review Date:** 9 June 2026
**Intended Status:** Informational
**Summary:** **Has Issues**

I have reviewed this document as part of the Security Directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the Security Area
Directors. Document authors, document editors, and WG chairs should treat
these comments just like any other last-call comments.

## Overview

This Informational document describes mapping 5G (3GPP) slices to IETF
Transport Network (TN) slices by repurposing the UDP source port of the
GTP-U bearer as the slice selector, read by a Provider Edge (PE) router
across an attachment circuit (AC).

The issues may or may not be very serious but they would seem to affect
the user above the protocol changes themselves so at least some warnings
about proper usage would be useful. Because the main field in use is
unauthenticated and trivially modifiable outside the "trusted operator
boundary" (Section 6) it feels like Security/Privacy Considerations need
some beefing up.

## Major Issues

### 1. The slice selector is forgeable and the threat is not analyzed

Slice selection — and hence resource allocation and isolation — hinges
entirely on the UDP source port. Any party able to inject or rewrite
packets on the CE to PE path can set an arbitrary source port.

This could lead to a couple of undesirable outcomes:

- steal premium-slice resources
- oversubscribe and starve a slice, breaking the isolation guarantee

Section 6 disposes of this in one sentence ("To avoid spoofing... ACLs and
IPsec must be deployed"). The document should give the concrete mitigation,
For example:
**PE ingress filtering that binds {AC / CE source address / VLAN} to a
permitted source-port range and drops mismatches.**

I appreciate this is alluded to, but it should be explicit in my view.

### 2. The IPsec discussion is contradictory

Section 3.3 (lines 658–668) requires the slice identifier to remain in the
cleartext outer header "even after IPsec encryption" so the PE can inspect
it, then says the GTP-U source port is "copied to the outer UDP
encapsulation source port." This conflicts with standard ESP-in-UDP
(RFC 3948), where the outer UDP ports are fixed (4500) and not available as
a variable slice selector.

More fundamentally, the draft never states the consequence: the
slice-selector field is **not integrity-protected**. If AH/ESP integrity
covered it, on-path PEs could not read or rewrite it; because they can, it
is spoofable. This contradiction must be resolved explicitly, with a clear
statement that the selector is unprotected and what that implies.

### 3. Metadata / confidentiality leak not acknowledged

Two things interact in an unfortunate fashion:
 - By design the selector is cleartext so the PE can classify on it. 
 - This document also makes reference to privacy considerations (RFC 9543
section 10, eg "It should not be possible for one IETF Network Slice
Service customer to discover the presence of other customers").

These 2 things together pose a small problem since privacy is affected
here: segments can be targeted and traffic analysis is possible. I'm not
sure exactly how serious this is but some networks may care and should
be told to consider the risk.

### 4. Security Considerations section is too thin

The section points to RFC 9543, RFC 9834, and the acaas-extn draft but
performs no analysis of its own mechanism. 

I subscribe to the idea that normative content is best avoided in Security
Considerations and security should be as straightforward as possible simply
by following the standard itself, so I'm not keen on stuffing obvious basics
or more protocol instructions in there. Even so, I'm surprised at the lack of
specific considerations given the trade-offs noted.

## Minor Issues

- **Management-plane / provisioning integrity (Sec. 3.2–3.3):** Isolation
  correctness depends on consistent CE-and-PE provisioning via the YANG
  model. Misconfiguration or NSC/management-plane compromise yields
  cross-tenant slice misassignment. Worth one sentence.
- **Load-balancing vs. selection conflict (Sec. 3.3, lines 677–681):**
  Overloading the source port as both ECMP entropy and slice selector forces
  range-based (coarser) validation at the PE, widening the spoofing surface
  and constraining entropy. Note the trade-off: this could go in Security
  Considerations.


## Nits

- Line 664: "AH (Authenticated Header)" is named **"Authentication Header."**
  in RFC 8221
- Line 665: "Encapsulated Security Payload" is **"Encapsulating Security
  Payload" (ESP).** in RFC 8221
- **AH is effectively deprecated** (RFC 8221 says ESP is preferred).
  Recommending AH is therefore is questionable; consider dropping AH or noting
  RFC 8221's point that ESP is preferred.