Subject: [Ntp] NTS IANA request

From: Watson Ladd <[email-masked]>
Date: Wed, 5 Jun 2019 10:19:11 -0700

Dear all,

Port 1009 is unassigned, and happens to be the time displayed on
watches in advertisements. No reason we couldn't continue old
tradition of using significant port numbers and use it for NTS.

We could also use 123 tcp which is assigned to NTP but not used.

Sincerely,
Watson Ladd

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 5 Jun 2019 15:21:10 -0700

> We could also use 123 tcp which is assigned to NTP but not used.

No.  The "NTP TCP Services" proposal is expecting to use TCP/123.

Let's not burn this port for a specific use-case.

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!

---

From: Daniel Franke <[email-masked]>
Date: Wed, 5 Jun 2019 19:18:13 -0400

According to RFC 6335,

> For any assignment request that includes a System Port, the assignment request MUST explain why a port number in the User Ports or Dynamic Ports ranges is unsuitable, and a reference to a stable protocol specification document MUST be provided.

Systems ports are those below 1024. I can't see any good technical
reason why NTS requires a system port rather than a user port and
don't think the above requirement can be satisfied.

On Wed, Jun 5, 2019 at 1:19 PM Watson Ladd
<watson=[email-masked]> wrote:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: "Gary E. Miller" <[email-masked]>
Date: Wed, 5 Jun 2019 16:48:13 -0700

Yo Harlan!

On Wed, 5 Jun 2019 15:21:10 -0700

> No.  The "NTP TCP Services" proposal is expecting to use TCP/123.

What services would they be?  Could some adjustments be made to make
NTP/TCP and NTS commpatible?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	[email-masked]  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin

---

From: Daniel Franke <[email-masked]>
Date: Wed, 5 Jun 2019 19:57:12 -0400

For a service to multiplex on the same port as NTS-KE, it's necessary and
sufficient that it run over TLS and that the services either be provided by
the same daemon or that some frontend that knows how to multiplex based on
ALPN, such as the nginx ssl_stream_preread module be put on front of it.
Ideally the other service should also use ALPN but that's not strictly
needed since you could send any client with an ntske/1 ALPN to NTS-KE, and
any client with no ALPN to the other service.

---

From: Hal Murray <[email-masked]>
Date: Wed, 05 Jun 2019 21:04:59 -0700

> No.  The "NTP TCP Services" proposal is expecting to use TCP/123.

Is there any documentation on what "NTP TCP Services" might be?

-- 
These are my opinions.  I hate spam.

---

From: Heiko Gerstung <[email-masked]>
Date: Thu, 6 Jun 2019 10:30:15 +0200

Since this is a system port and we will, as already discussed, have a hard time to convince IANA, why not use 36540. This is the number of seconds since midnight at 10:09 ;-) ... And as far as I can tell, it is unassigned too.

Cheers,
   Heiko

-- 
Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre Hartmann, Heiko Gerstung

Email:
 [email-masked] 
Web:
 Deutsch   https://www.meinberg.de
 English    https://www.meinbergglobal.com

Do not miss our Time Synchronization Blog:
 https://blog.meinbergglobal.com 

Connect via LinkedIn: 
https://www.linkedin.com/in/heikogerstung

On 05.06.19, 19:20 "ntp im Auftrag von Watson Ladd" <[email-masked] im Auftrag von watson=[email-masked]> wrote:

    Dear all,

    
    Sincerely,
    Watson Ladd

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 6 Jun 2019 11:58:39 +0200

> Since this is a system port and we will, as already discussed, have a hard time to convince IANA, why not use 36540. This is the number of seconds since midnight at 10:09 ;-) ... And as far as I ca…

Or 14995, which is 'NTS' in "5-bit" ASCII characters.

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Jun 2019 14:57:30 +0000

If you pick a number greater than 1024 traffic will be blocked by most firewalls.  It will still be blocked by default, but opening a firewall to use a "privileged" port is much easier than opening a random port number.

As for "IANA won't give us one," has anyone asked?

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Jun 2019 15:06:08 +0000

There are typically two ways this is done.  Peek at the first few bytes and if it looks like a command, assume it's plaintext; many web servers, for example, peek for G E T. The other way is to add a new command to NTP/TCP that says STARTSSL, just like SMTP, NNTP, etc.

The first requires implementers to do the work; the second also requires implementors, but anyone can draft an RFC to add the command :)

---

From: Daniel Franke <[email-masked]>
Date: Thu, 6 Jun 2019 11:29:29 -0400

> As for "IANA won't give us one," has anyone asked?

Not that I know of. I don't think this is a very persuasive argument
but if you can get IANA to buy it I won't argue against you.

---

From: Daniel Franke <[email-masked]>
Date: Thu, 6 Jun 2019 13:01:50 -0400

I'm strongly opposed to modifying NTS-KE to involve sending a STARTTLS
as a first step of the handshake. I don't want to make a breaking
change to a protocol that's passed WGLC and has four interoperating
implementations in order to accommodate a protocol that has never been
implemented and whose specification consists of three vague sentences
in an unadopted and expired I-D.

If the WG wants to take 123/tcp away from NTP and re-assign it to
NTS-KE, fine. But in that case it should be assigned to the existing
form of NTS-KE, which is a protocol whose immediate first step is to
perform TLS handshake with mandatory ALPN, and any future protocols
which wish to co-exist on 123/tcp will have to operate within the
constraints that that creates.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 6 Jun 2019 17:05:37 +0000

I wasn't strongly advocating either mechanism, just trying to explain how things could share a port if that's what we wanted to do.

For the record, since I see no definition of NTP/TLS, I am in favor of assigning 123/TCP to NTS.

---

From: Daniel Franke <[email-masked]>
Date: Thu, 6 Jun 2019 14:28:28 -0400

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:

1. We're never going to persuade enough ISPs to change their policy,
making 123/udp basically doomed.
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.

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.

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 6 Jun 2019 14:42:12 -0700

As best as I can tell, the following is total rubbish.

H

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 6 Jun 2019 20:24:42 -0700

My response was intended to be a technical response.

I don't have the time or the desire to refute all of the wrong claims in
this thread.

H

On 6/6/2019 8:23 PM, [email-masked] wrote:
> Harlan,
> 
> As we have discussed privately, this type of email response is not helpful.
> Please limit your comments on the mailing list to specific technical
> concerns.
> 
> Thank you!
> Karen
> 
> On 6 Jun 2019, at 17:42, Harlan Stenn wrote:
> 
>>>> I wasn't strongly advocating either mechanism, just trying to
>>>> explain how things could share a port if that's what we wanted to do.
>>>>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 06 Jun 2019 23:23:33 -0400

Harlan,

As we have discussed privately, this type of email response is not 
helpful.
Please limit your comments on the mailing list to specific technical 
concerns.

Thank you!
Karen

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 06 Jun 2019 23:29:54 -0400

Harlan,

Saying something is “total rubbish” is not actionable by the working 
group. You have several other options in this case…

You can indicate that you don’t agree with the technical points being 
made either individually or as a set.

Or, you can indicate that you don’t agree with the statement that the 
working group has concluded the specific points made.

If you don’t have time to comment on specific questions you can 
indicate that as well.

But I ask you, and all working group members to maintain a certain level 
of professionalism on the mailing list.

Thank you!
Karen

On 6 Jun 2019, at 23:24, Harlan Stenn wrote:

>>>>>>    I'm strongly opposed to modifying NTS-KE to involve sending 
>>>>>> a
>>>>>> STARTTLS
>>>>> For the record, since I see no definition of NTP/TLS, I am in 
>>>>> favor
>>>>> of assigning 123/TCP to NTS.
>>>>>
>>>>>
>>>>

---

From: Heiko Gerstung <[email-masked]>
Date: Fri, 7 Jun 2019 09:40:32 +0200

I initially wanted to have an IANA assigned port for NTP-over-NTS to make it easier for users to manage their firewall settings. As we know, quite a number of ISPs and corporate firewall admins created these size-limiting rules in the wake of the amplification attacks carried out via the monlist feature a while ago. Now, I do not see the problem that an IANA assigned well known port will be hit by the same firewall rules, as for the ISPs it requires most probably to create a new firewall rule (and do not put stringent packet size limits in it), if they set up a rule at all.

In order to simplify firewall handling for corporate users/non-ISPs, I would recommend the well known port but obviously the NTS-KE mechanism to advertise a different port is still a good option in case some people prefer that.

My suggestions: register a port (it does not really have to be a system port IMHO), use that as a default for the NTS-KE port advertising and allow users to change it. This way, someone can even use 123/udp again if they see fit.

Regards,
   Heiko

-- 
Heiko Gerstung 
Managing Director

Email:

Connect via LinkedIn: 

On 06.06.19, 20:29 "ntp im Auftrag von Daniel Franke" <[email-masked] im Auftrag von [email-masked]> wrote:

---

From: Hal Murray <[email-masked]>
Date: Fri, 07 Jun 2019 03:14:34 -0700

> My response was intended to be a technical response.

There is no technical content in "total rubbish". 

> I don't have the time or the desire to refute all of the wrong claims in this
> thread. 

I thought Daniel's message looked good.

If it's "total rubbish", it shouldn't take long to point out some of the problems and/or point out the most obvious fatal flaw.

--------

I have a data point to contribute.

>From Daniel's message:
> 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: 

I have 2 cloud servers in the pool, one in San Francisco, the other in London.  As part of the NTS hackathon a month or two ago, they were helping to debug NTS.

There were problems getting NTP+NTS packets to the server in London.  I forget the details.  Nobody seemed surprised.  There was at least one "we've seen it before" comment.

Has anybody done a survey?  Is there a non-NTS packet over 48 bytes that most servers will respond to?

---

From: Danny Mayer <[email-masked]>
Date: Fri, 7 Jun 2019 10:31:04 -0400

> in order to run NTP-with-NTS over an alternate port.

We do what we did for EDNS0, get the firewall folks to change their
policies to allow for larger payloads. It will takes years but firewall
people have to move with changes as they happen.

Danny

---

From: Warner Losh <[email-masked]>
Date: Fri, 7 Jun 2019 08:32:42 -0600

> There is no technical content in "total rubbish".

In this instance.... The problem here is not the two words, per se, but
that the message it was in response to had multiple items, so it was
ambiguous. Had he said the idea of using clear text passwords over the
internet was total rubbish, that would be fine and actionable because it's
specific.

Warner

---

From: Daniel Franke <[email-masked]>
Date: Fri, 7 Jun 2019 13:34:22 -0400

> people have to move with changes as they happen.

EDNS0 may literally be the worst possible role model here. It made DNS
a serious amplifier, the internet's second-worst offender after NTP.
It *created* the problems that those firewall rules were put in to
solve. Today if you want to make a DNS request whose response is
likely to be larger than 512 bytes, you're practically forced to do it
over TCP.

---

From: Watson Ladd <[email-masked]>
Date: Fri, 7 Jun 2019 10:38:57 -0700

> people have to move with changes as they happen.

We do not need to inflict unnecessary pain on ourselves. Measuring is
happening and I know at least one instance of apparent packet loss that was
actually a comparability failure.

However we may need to move ports and should figure out a way to do so.
Another request sounds fine.

---

From: "Majdi S. Abbas" <[email-masked]>
Date: Fri, 7 Jun 2019 16:08:33 -0400

> 123/udp traffic with payloads larger than 48 bytes. I think we got as

	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.

> 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.

> in order to run NTP-with-NTS over an alternate port.

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

> for corporate firewalls with a default-deny-all policy to let us

	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

---

From: Daniel Franke <[email-masked]>
Date: Fri, 7 Jun 2019 16:32:11 -0400

> have corrected their configurations.

It's been ours. We've encountered such filtering issues in all three
NTS hackathons. At any rate, as Watson said, data is coming. We should
rely on that rather than anecdotes.

> has not in a very long time.

This isn't an issue of system ports (< 1024) vs. user ports, it's an
issue of a single IANA-registered port vs. everyone who runs a server
being told to choose their own (and advertise it via NTS-KE port
negotiation). In the latter case it becomes both harder to block if
you have a default-allow policy like an ISP would, and harder to allow
if you have a default-deny policy like a corporate firewall would.

---

From: "Majdi S. Abbas" <[email-masked]>
Date: Fri, 7 Jun 2019 16:55:05 -0400

> rely on that rather than anecdotes.

	Sure, but if you can tell me which providers/networks are
involved, I'd be happy to have a chat with them.

> if you have a default-deny policy like a corporate firewall would.

	Well, so far we've already had one assertion that NTS
"needs" a privileged port on this list -- it may not have been yours,
but that was the assertion I was replying to.

	Thanks!

	--msa

---

From: Watson Ladd <[email-masked]>
Date: Fri, 7 Jun 2019 19:49:25 -0700

> likely to be larger than 512 bytes, you're practically forced to do it

NTP? There are no mode 6 packets in RFC 5905.

Let's be clear about what happened: one implementation did something silly
and we have to clean up the mess. And to compound the problem src=123 is
used for queries by that same implementation so time servers can't block
the amplification easily and still be useable by the widely shipped
implementation.

I'm still jumping through hoops because of this.

Sincerely,
Watson

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 7 Jun 2019 22:15:47 -0700

On 6/7/2019 7:49 PM, Watson Ladd wrote:
> 
> 
> On Fri, Jun 7, 2019, 10:34 AM Daniel Franke <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     On Fri, Jun 7, 2019 at 10:31 AM Danny Mayer <[email-masked]
>     <mailto:[email-masked]>> wrote:

How is this relevant?

> Let's be clear about what happened: one implementation did something

Point of order: is this a technical comment?  Is it professional?

The implementation was behaving as it did pretty much from before 1989 -
it was in xntp2, and I haven't checked anything earlier.

Back from when the "internet" was a friendly and helpful place.

The Reference Implementation required a token for MRU lists, the vehicle
for the amplification attack starting in late March of 2010.

The 'monitor' keyword was added in July of 2010.

The 'mode7' keyword was added in November of 2011.

The big NTP attacked happened in December 2013.

Folks had more than 2 years to decide to upgrade.

But none of these attacks, NTP, DNS, etc. would have been possible had
folks implemented BCP38, which was published in May of 2000.

> and we have to clean up the mess.

If you mean the NTP WG, then we disagree.

We have responsibilities *to* people, not *for* people.

If folks choose not to upgrade their software, or to not bother with BCP
on traffic or configurations, against recommendation, that's their
choice.  It is arguably irresponsible, but it's still their choice.

> And to compound the problem
> src=123 is used for queries by that same implementation so time servers
> can't block the amplification easily and still be useable by the widely
> shipped implementation. 

How exactly would not using 123 for queries allow folks to block
amplification?  The forged packets were likely not coming from port 123.

Your assertion makes no sense to me.  Perhaps you could rephrase it for
me and anybody else who doesn't know what you're trying to say.

> I'm still jumping through hoops because of this.

In what way?

>     [email-masked] <mailto:[email-masked]>

---

From: Watson Ladd <[email-masked]>
Date: Sat, 8 Jun 2019 00:12:28 -0700

> folks implemented BCP38, which was published in May of 2000.

There are many places where these problems could be solved. That
doesn't free us from having to deal with them.

> amplification?  The forged packets were likely not coming from port 123.

The issue isn't with being an amplifier, the issue with being the
victim of an amplifier. Blocking src = 123 is an easy solution for the
network team, but makes it impossible to operate a time service
without blocking those users who use the reference implementation. So
operators of NTP servers have to decide: be vulnerable to DDOS or not
support common clients. This is not good.

> > I'm still jumping through hoops because of this.

The details aren't that interesting and mostly concern assumptions
that get broken by the solution to the above problem of putting the
server on its own ip range with its own firewall rules which are not
protected.

--
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 11 Jun 2019 08:25:26 +0200

Hi!

Actually I think traffic limiting rather than traffic blocking would have been
the more correct approach against amplification attacks.  Anf of course a more
specific blocking rule than just blocking 123/UDP completely.

Regards,
Ulrich

>>> Heiko Gerstung <[email-masked]> schrieb am 07.06.2019 um 09:40
in
Nachricht <[email-masked]>:
> I initially wanted to have an IANA assigned port for NTP-over-NTS to make it

> easier for users to manage their firewall settings. As we know, quite a 
> number of ISPs and corporate firewall admins created these size-limiting 
> rules in the wake of the amplification attacks carried out via the monlist 
> feature a while ago. Now, I do not see the problem that an IANA assigned
well 
> known port will be hit by the same firewall rules, as for the ISPs it 
> requires most probably to create a new firewall rule (and do not put 
> stringent packet size limits in it), if they set up a rule at all.
> 
> In order to simplify firewall handling for corporate users/non-ISPs, I would

> recommend the well known port but obviously the NTS-KE mechanism to
advertise 
> a different port is still a good option in case some people prefer that.
> 
> My suggestions: register a port (it does not really have to be a system port

> IMHO), use that as a default for the NTS-KE port advertising and allow users

> to change it. This way, someone can even use 123/udp again if they see fit.
> 
> Regards,
>    Heiko
> 
> 
> 
> -- 
> Heiko Gerstung 
> Managing Director
> 
> On 06.06.19, 20:29 "ntp im Auftrag von Daniel Franke" <[email-masked]

> im Auftrag von [email-masked]> wrote:
> 
>     >     implementations in order to accommodate a protocol that has never

> been
>     > I wasn't strongly advocating either mechanism, just trying to explain

> how things could share a port if that's what we wanted to do.
>     >
>     > For the record, since I see no definition of NTP/TLS, I am in favor of

> assigning 123/TCP to NTS.
>     >
>     >
>