Re: [Ntp] NTS IANA request

["Majdi S. Abbas" <[e-mail]>]

On Thu, Jun 06, 2019 at 02:28:28PM -0400, Daniel Franke wrote:
> As a slight tangent, we never concluded the discussion as to what
> we're going to do about the fact that so many ISPs are dropping
> 123/udp traffic with payloads larger than 48 bytes. I think we got as
> far as concluding:

	At least in the case of two major carriers that did deploy
filters early on, that's not actually what they are doing.

	They're peeking at a specific offset to look for large monlist
replies.  They were absolutely not filtering all NTP traffic above 48
bytes; and I have not seen that behavior in production networks.
(Such a filter is actually difficult to implement since it has to work
in hardware that exists in linecards already.  It's easier to peek at
a specific offset than decode size and do a comparison the value.)

	Another large carrier, run by some pretty sharp folks, simply
rate limits large NTP payloads, but does not deny it. This should be
fine for key exchange or some sort of other initial session setup.

	I only ran into issues with one of them -- which they corrected
when I had a conversation with them about it.

> 1. We're never going to persuade enough ISPs to change their policy,
> making 123/udp basically doomed.

	I'm not sure where this came from, but it hasn't been my 
experience.  In fact even the folks who came in with pretty heavy
handed filters a few years ago, have backed off quite a bit as users
have corrected their configurations.

> 2. NTS-KE's port negotiation record gives us all the mechanism we need
> in order to run NTP-with-NTS over an alternate port.

	I'm not sure that's necessary, or sufficient.  

> But that left an unresolved question: do we allocate a fixed alternate
> UDP port, or should servers ask the OS for a dynamic port and then use
> NTS-KE to advertise whatever the OS assigns to them? Both choices have
> firewall-related drawbacks. If we use a fixed port, we risk landing
> ourselves right back in the same situation we're in today with 123. At
> minimum, to protect ourselves from this, the NTF would have to commit
> to adding some code to ntpd such that it will refuse to ever send mode
> 6 or 7 responses over the new port no matter what configuration the
> user gives it. (Yes, mode 6 too, because mode 6 still amplifies, just
> not as severely as mode 7 does). If we use a dynamic port, then it
> becomes much harder for ISPs to block us, but it also becomes harder
> for corporate firewalls with a default-deny-all policy to let us
> through.

	I don't believe there's much of a firewall issue at all,
since I haven't seen a blanket "lt 1024" permit in.... years.  Either
specific services are permitted, or application level proxies are
employed... but nobody magically "trusts" system ports any more, and
has not in a very long time.

	--msa