On 31/07/2026 20:08, Kaippallimalil John wrote:
Hi Gorry,Thank you for reviewing and providing these comments. A few short notes on changes: - re: comment on source port randomization - now stated explicitly to note this as a security consideration and ref to RFC8085,section 5.1.1. - revised UDP source port space to standard ephemeral source port space assigned by IANA. - 3GPP TS28.541 (NRM spec) should probably be left as Normative. Attachment circuits in 28.541 are mapped via ConnectionPointInfo (6.3.41) and EP_Transport (6.3.18). This links it to IETF ACaaS (UDP source port). Moved RFC9543 to 9.2 (Informative References) as it is an informative document. - RE: GTP-U /using the IPv6 flow label for mapping - it's probably beyond the considerations in this document. (the approach seems like a good idea and can be looked into for another draft perhaps) Link: https://www.ietf.org/archive/id/draft-ietf-dmm-tn-aware-mobility-30.txt Diff: https://author-tools.ietf.org/iddiff?url2=draft-ietf-dmm-tn-aware-mobility-30 Best Regards, John
Thanks John, This sounds like you have addressed my comments. Shouldn't https://datatracker.ietf.org/doc/html/rfc768 also be referenced? Best wishes, Gorry
-----Original Message----- From: Gorry Fairhurst via Datatracker <[email protected]> Sent: Thursday, July 30, 2026 1:41 AM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; draft-ietf-dmm-tn-aware- [email protected]; [email protected] Subject: Gorry Fairhurst's No Objection on draft-ietf-dmm-tn-aware-mobility- 29: (with COMMENT) 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://ww/ w.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot- positions%2F&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7C ddf28f069e884577a06408deee0579a0%7C0fee8ff2a3b240189c753a1d559 1fedc%7C1%7C0%7C639209904454959592%7CUnknown%7CTWFpbGZsb3 d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=LwGdafY4nZ4E mNDdBWpoSH2J9MSPQSLLu79edcBpmTA%3D&reserved=0 for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://data/ tracker.ietf.org%2Fdoc%2Fdraft-ietf-dmm-tn-aware- mobility%2F&data=05%7C02%7Cjohn.kaippallimalil%40futurewei.com%7Cd df28f069e884577a06408deee0579a0%7C0fee8ff2a3b240189c753a1d5591 fedc%7C1%7C0%7C639209904455021581%7CUnknown%7CTWFpbGZsb3d 8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkF OIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Wr8VGO64ckf GLLOYiLnecfEDQf5BFP7ppe4k3JiGBks%3D&reserved=0 ---------------------------------------------------------------------- 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 mailing list -- [email protected] To unsubscribe send an email to [email protected]
