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

[Hal Murray <[e-mail]>]

[e-mail] 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.