hi Fernando, > On 25 Feb 2021, at 10:17, Fernando Gont <fgont@xxxxxxxxxxxxxxx> wrote: > > 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. Yep, I get that. My comment is a little more subtle. There is a tradeoff, however small, that an endpoint deployed *without* cooperation or knowledge of a NAT or firewall on path might risk connectivity by randomizing ports. Are there any known firewall/NAT deployments that require 123/123 on both src and dst to recognize NTP? Is there anything a port-randomizing NTP speaker can/must do to detect and react to this situation (even if that's throwing up an error message and asking the kind human looking after the thing to please unbreak their firewall)? (That said, this is really a tiny nit. I'm perfectly fine with you considering this and deciding it doesn't warrant text in the doc) Thanks, cheers, Brian > > 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
