Re: [Ntp] Tsvart last call review of draft-ietf-ntp-port-randomization-06

[Fernando Gont <[e-mail]>]

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: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492