ietf@xxxxxxxxxxx said: > 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)? There is nothing in an NTP packet that needs tweaking by a NAT box other than the obvious return address. So there is no reason to recognize it as an NTP packet. More details than anybody wants to know... There was/is(?) Autokey, RFC 5906, an early attempt at public key authentication. It didn't work through NAT because the client IP Address was tangled up in the crypto. I don't think anybody uses it. We removed support from NETSec. But who knows what unattended code is still running in some dusty corner. Some of the mode 6/7 subcommands use a cookie to prevent DDoS amplification. The client doesn't know anything about the contents of the cookie. The cookie includes a hash of the clients IP Address but that works through NAT as long as the client uses the same NAT box to both request and use the cookie. NTS uses cookies, but there is nothing about the IP Address included in the cookie. We discussed adding the IP Address. I have forgotten exactly why. Probably to avoid reflection attacks. We decided not to do that. -- These are my opinions. I hate spam. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
