[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)
- [DMM] Gorry Fairhurst's No Objection on draft-iet… Gorry Fairhurst via Datatracker
- [DMM] Re: Gorry Fairhurst's No Objection on draft… Kaippallimalil John
- [DMM] Re: Gorry Fairhurst's No Objection on draft… Gorry Fairhurst
- [DMM] Re: Gorry Fairhurst's No Objection on draft… Kaippallimalil John