Subject: Re: [Ntp] NTS Hackathon coordination

From: Hal Murray <[email-masked]>
Date: Fri, 22 Mar 2019 15:32:10 -0700

[email-masked] said:
>    For those participating, I’ll see you physically or virtually tomorrow.
>    The room will open at 9:00 am CET. It will take us a little while to get
>    started and get through the opening portions, so for the remote folks,
>    please be patient with us. 

I assume somebody will find bugs/quirks in our code.  I'll be available via 
email.  I'm in California.  I think that means you are starting at my 
midnight.  I'm a night owl, so we'll get some overlap.

2 more servers:
  ntp1.glypnod.com - San Francisco
  ntp2.glypnod.com - London

The NTS-LE server is listening on port 123, both IPv4 and IPv6.

I've seen cases where some NTP packets don't make it to London.  I assume it's 
filtering leftover from the DDoS mess of a few years ago.  Normal NTP 
request/responses get through.  Longer requests with NTS extensions don't get 
in to London if the source port is 123.

-- 
These are my opinions.  I hate spam.

---

From: "Dieter Sibold" <[email-masked]>
Date: Sat, 23 Mar 2019 09:18:34 +0100

Hi Hal,
I’ve added both of the addresses to
https://docs.google.com/spreadsheets/d/1nZ0XLkpPUVAlThLhnjp4CjJ-XnwfPPFWHNxLlp9UCyM/edit#gid=0

Maybe you can add the parameters that are needed for a client to 
connect.

Regarding your observations of dropped NTP packets. We experienced this 
behavior also during the Hackathon in Montreal.

Dieter Sibold
[email-masked]

On 22 Mar 2019, at 23:32, Hal Murray wrote:

> [email-masked] said:
>>    For those participating, Iâll see you physically or virtually 
>> tomorrow.
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Hal Murray <[email-masked]>
Date: Sat, 23 Mar 2019 01:54:35 -0700

[email-masked] said:
> Maybe you can add the parameters that are needed for a client to  connect. 

We are using the same extension types as Martin Langer, Ostfalia.

If somebody decides some other numbers are preferable, we can easily switch.

---

From: Daniel Franke <[email-masked]>
Date: Sat, 23 Mar 2019 12:37:55 +0100

We need to get the word out to network operators to stop filtering in this
manner (and that if they really must filter, they should limit it to mode 7
packets). As a (hopefully) temporary measure, implementers should make it
easy for users to serve NTP on an alternate port in addition to 123, and
use Port Negotiation in NTS-KE to advertise it. There should be no need for
any spec changes or IANA actions to accommodate this behavior; since we
have the negotiation mechanism, there is no need for a registered port and
administrators can pick anything not in use by another service.

On Fri, Mar 22, 2019, 23:32 Hal Murray <[email-masked]> wrote:

>
> [email-masked] said:
> >    For those participating, Iâ€™ll see you physically or virtually
> tomorrow.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 23 Mar 2019 13:45:24 +0100

We had a similar conversation with our network people at work.
Apparently ASICs are bad at looking inside packets, even at fixed bit
positions inside packets. They are limited to port, udp or tcp, and
length.

On Sat, Mar 23, 2019 at 12:38 PM Daniel Franke <[email-masked]> wrote:
>
> We need to get the word out to network operators to stop filtering in this manner (and that if they really must filter, they should limit it to mode 7 packets). As a (hopefully) temporary measure, implementers should make it easy for users to serve NTP on an alternate port in addition to 123, and use Port Negotiation in NTS-KE to advertise it. There should be no need for any spec changes or IANA actions to accommodate this behavior; since we have the negotiation mechanism, there is no need for a registered port and administrators can pick anything not in use by another service.
>
>> >    For those participating, Iâ€™ll see you physically or virtually tomorrow.

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 27 Mar 2019 10:31:42 +0100

On Sat, Mar 23, 2019 at 12:37:55PM +0100, Daniel Franke wrote:
> packets).

And mode 6 packets, which still seem to be enabled by default in the
implementations that support it.

> As a (hopefully) temporary measure, implementers should make it

That won't work with firewalls which have whitelisted UDP ports. This
is a common practice in some environments. (Stateful firewalls can't
get the number from the encrypted NTS-KE.)

I think we should specify an alternative port for NTP, where modes 6
and 7 are not allowed. The port 123 is doomed. It's increasingly
difficult to find an ISP that doesn't block the port. Some large
network operators seem to limit rate of packets using that port. Two
of my public servers recently became unusable for this reason. Nobody
cares.

Blocking and rate limiting of the port is probably the main reason why
the number of public servers is still dropping 5 years after the
amplification attacks started.

-- 
Miroslav Lichvar

---

From: "Ulrich Windl" <[email-masked]>
Date: Wed, 27 Mar 2019 11:03:58 +0100

>>> Miroslav Lichvar <[email-masked]> schrieb am 27.03.2019 um 10:31 in
> implementations that support it.

As a side-note: Our university also had blocked almost all NTP traffic to the
outside, making NTP pool servers ridiculous: The client gets a long list of
addresses through DNS, but cannot reach any of those. If you compare that to
some multicast/manycast solution, the client wouldn't receive any server. I'd
prefer the second.

In the past I could query various "outside" servers, even with mode 6 packets.
I don't like the state as it is now, but if there's threat (mostly by lawyers
claiming refund for denial of service originating from the universitiy's
network) the security people shut down service. More and more services get shut
down here...

>> use Port Negotiation in NTS‑KE to advertise it. There should be no need
for
> get the number from the encrypted NTS‑KE.)
> 
> ‑‑