Hi, Brian, Thanks so much for you comments! In-line... On 23/2/21 16:15, Brian Trammell via Datatracker wrote: [....]
This document is ready from a transport standpoint. It describes an already-implemented, relatively-straightforward application of an existing BCP to a well-understood protocol, and is clearly written. I especially appreciated the complete set of considerations, covering situations in which NTP port randomization could cause issues with certain deployment scenarios. The effect of routing on NTP is well studied (one such study is cited in the draft), and sections 3.3 and 3.4 discuss how this draft could interact with on-path modification of NTP traffic. Herein lies my only nit with the draft: it would be nice if 3.3 and 3.4 discussed how an NTP-speaking endpoint could detect and react to issues caused by misconfigured filtering or NAT.
You mean issues caused by packet filtering meant to mitigate DoS attacks? If the service port is used (src=dst=123), it'd be impossible (from the layer-4 header) to tell client or server traffic. So one would resort to dropping all traffic, or no traffic. BUt if port randomization is employed, client traffic will employ an ephemeral port and thus it becomes possible to distinguish client/server traffic by looking at the transport protocol port numbers -- i.e., port randomization helps in this scenario.
Similarly, in the case of mis-configured NATs (I'm assuming that you're referring to NATs not translating service ports) doing port randomization would actually allow for multiple clients to work across NATs, since there wouldn't be conflicting uses of the service port on the NAT internal realm.
i.e., in both cases, port randomization actually helps in these two scenarios.
Please do let me know if I've misinterpreted your comment. Thanks! Regards, -- Fernando Gont SI6 Networks e-mail: fgont@xxxxxxxxxxxxxxx PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
