On 26/2/21 07:04, Brian Trammell (IETF) wrote:
[....]
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?
I don't know of any. And it would be *very* surprising to find those,
for the following reasons:
1) There's only one implementation that I know of that uses the service
port as the source port of client requests. As a ressult, enforcing
such a rule would prevent all other implementations from working.
2) Even in the case f an implementation that employs 123 for the source
port, in a very large number of cases, for the IPv4 case,the packets
will go through one or more NATs (CPE NAT and possibly CGN), so in
the most common client deployment cases, the source port will not be
prevented anyway.
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)?
I would argue that there's nothing special to do here.
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
