Subject: [Ntp] [[email-masked]: New Version Notification for draft-gruessing-ntp-ntpv5-requirements-01.txt]

From: James <[email-masked]>
Date: Wed, 30 Dec 2020 03:17:38 +0000

All,
I've published a new version based on recent conversations and email threads
on this list, as well as a few contributions from Doug Arnold.

As always, your feedback would be appreciated. 

- J

----- Forwarded message from [email-masked] -----

Date: Tue, 29 Dec 2020 18:58:51 -0800
From: [email-masked]
To: James Gruessing <[email-masked]>
Subject: New Version Notification for
 draft-gruessing-ntp-ntpv5-requirements-01.txt

A new version of I-D, draft-gruessing-ntp-ntpv5-requirements-01.txt
has been successfully submitted by James Gruessing and posted to the
IETF repository.

Name:		draft-gruessing-ntp-ntpv5-requirements
Revision:	01
Title:		NTPv5 use cases and requirements
Document date:	2020-12-29
Group:		Individual Submission
Pages:		7
URL:            https://www.ietf.org/archive/id/draft-gruessing-ntp-ntpv5-requirements-01.txt
Status:         https://datatracker.ietf.org/doc/draft-gruessing-ntp-ntpv5-requirements/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-gruessing-ntp-ntpv5-requirements
Htmlized:       https://tools.ietf.org/html/draft-gruessing-ntp-ntpv5-requirements-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-gruessing-ntp-ntpv5-requirements-01

Abstract:
   This document describes the use cases, requirements, and
   considerations that should be factored in the design of a successor
   protocol to supercede version 4 of the NTP protocol [RFC5905]
   presently referred to as NTP version 5 ("NTPv5").  This document is
   non-exhaustive and does not in its current version represent working
   group consensus.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

----- End forwarded message -----

---

From: Magnus Danielson <[email-masked]>
Date: Wed, 30 Dec 2020 19:51:26 +0100

Hi,

> As always, your feedback would be appreciated. 

Pondering on the implications more than what you written.

Now saying that UTC must be supported (3.3 Timescales) is great, the
leap second smearing (3.4.1 Leap second smearing) states that it must be
possible to establish the unsmeared time, which is also great.

Now, technically this can be done using one of two techniques:

1) The offset is transmitted so it can be compensated.

2) The offset is determinable through a set of parameters in a model.

Then, two different transmit time-scales can be used:

A) Maintain an unsmeared transmit timescale

B) Use a smeared transmit timescale

I intentionally did not say specifics of the transmit timescales on
either, except for the peculiarity of them being smeared or not.

Since both 1) and 2) in combination with A) and B) will able to deliver
both the access to unsmeared and smeared timescales, providing 4
different combinations.

I think we shall consider the consequence for implementations as you
consider the different cases, and also as you now monitor multiple servers.

I think there is a strong benefit of keeping the transmit timescale as
simple as possible, so all the various checks can be done. I think this
rules out or at least the B variants less attractive.

Using an offset value as in 1) has several benefits and can be used for
other uses, but requires additional value to always be transported. This
may be problematic for many.

Using a model with parameters 2) require us to get these parameters
before we can access the modelled time-scale, an there is upstart issues
as well as the upgrade of parameters. Those issues can be worked out
with some care, and there is examples where it works well when properly
implemented. A benefit is that it does not require a high rate of
additional information.

This leads me to towards the 2A corner of solution space. This is inline
with my standpoint to make smearing or other time-scale adaptation a
client-side issue. I think it will be the easiest way to support
multiple time-scales this way, as being the intention (3.3. Timescales).

Cheers,
Magnus

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Hal Murray <[email-masked]>
Date: Thu, 31 Dec 2020 01:46:26 -0800

Looks good.  Thanks.

Suggested additions:

A section on DDoS avoidance.
  History
  Mention pain-in-ass random blocking.
  No amplification.
    Request extensions must be as large as replies.
  Rate limiting
  Both OK with something like a cookie that verifies that the request came 
from the return address or from an approved address.

We should split out implementation details.
  Yet be sure to describe important considerations like PLL 
overshoot/oscillation.

We should be NAT friendly.

-- 
These are my opinions.  I hate spam.

---

From: James <[email-masked]>
Date: Thu, 31 Dec 2020 13:43:44 +0000

Thanks for the feedback.

Since these will require a bit of thought and discussion I have
created a few Github issues[1] based off this feedback; people's 0.02c
on them or even suggestions for text would be greatly appreciated.

- J

1: https://github.com/fiestajetsam/I-D/issues?q=is%3Aissue+is%3Aopen+label%3Antp-ntpv5-requirements

---

From: Magnus Danielson <[email-masked]>
Date: Thu, 31 Dec 2020 15:31:18 +0100

James,

I left some feedback already.

As for implementation details, we should provide useful hints as
non-normative appendixes. We can update those as informative RFCs in the
future. It will impact the performance, and it would only be particular
need that put requirement on such performance measures is in place.

I think the amplification rule needs severe rewording, as it will cause
bad limitation to protocol design. The problem is really not
amplification, it's the ability to spoof the wrong return address which
comes from unauthorized UDP connection free relationship, which is not
what we should aim for, for future generations. The "bug" of the
management interface is not the amplification, it's the redirectability.
That's what we should aim for. That you can get severely larger answers
than you sent is only a problem if you can redirect the replies. As we
step major revision, saying such management requests needs to be done in
a session with some reasonable security should not be an issue, but a
well tested solution, so TCP and TLS requirement should avoid the main
issues, and the amplification is no longer an issue, but a feature to
get a lot of useful data, just that we ensure it cannot become a DDOS tool.

Cheers,
Magnus