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 > -----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]
