[DMM] Gorry Fairhurst's No Objection on draft-ietf-dmm-tn-aware-mobility-29: (with COMMENT)

Gorry Fairhurst via Datatracker <noreply@ietf.org> Thu, 30 July 2026 06:40 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: dmm@ietf.org
Delivered-To: dmm@mail2.ietf.org
Received: from [10.244.21.25] (gaia.k8s.ietf.org [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id 85F29120E24CB; Wed, 29 Jul 2026 23:40:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1785393640; bh=BQyKLZUIAoW/k4oOBAbzbzaSqTQ8L766nE1WKo7RJRM=; h=From:To:Cc:Subject:Reply-To:Date; b=a668hdMN1KtuAqY17jRe2z9n8m/1H8bPKqAiVbNa7QeuDEio3B5yrJPQKfzMtN/n2 Wt1P3XvFzND50Cq2IKTy7E+VVwDP1nwnWltKcTzg9/U9Pz2BCS5GnZ++BdRNShbpaM +d+ZGKhO2DGBGveqkSioSGZIV4kZRbwkYMwnNamM=
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Gorry Fairhurst via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.69.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <178539364043.1476276.1255749494415309869@dt-datatracker-d4d6ff9d9-fsx7d>
Date: Wed, 29 Jul 2026 23:40:40 -0700
Message-ID-Hash: P2WNR6VGNPVNAL5SP2JX3XKTGE6CDBOO
X-Message-ID-Hash: P2WNR6VGNPVNAL5SP2JX3XKTGE6CDBOO
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dmm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dmm-chairs@ietf.org, dmm@ietf.org, draft-ietf-dmm-tn-aware-mobility@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: [DMM] Gorry Fairhurst's No Objection on draft-ietf-dmm-tn-aware-mobility-29: (with COMMENT)
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/HPBt1JDLLG-QaN3obK9yUSE6oAs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Owner: <mailto:dmm-owner@ietf.org>
List-Post: <mailto:dmm@ietf.org>
List-Subscribe: <mailto:dmm-join@ietf.org>
List-Unsubscribe: <mailto:dmm-leave@ietf.org>

Gorry Fairhurst has entered the following ballot position for
draft-ietf-dmm-tn-aware-mobility-29: 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:
----------------------------------------------------------------------

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.

### 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! — What is the
dependency upon TS.28.541-3GPP? — Is the reference to UDP normative - if not,
why? — 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?).

Gorry Fairhurst
(updated comments)