Re: [Ntp] New Version Notification for draft-gruessing-ntp-ntpv5-requirements-03.txt

[[e-mail]]

> >>> Encryption and authentication MUST be provided by the protocol 
> specification as a default and MUST be resistant to downgrade attacks...
> >>
> >> To put this another way, I think the specification must provide 
> confidentiality as well as authentication, and that if either is 
> applied they cannot be removed from a connection (aka a security 
> downgrade) which makes authentication the minimum and doesn?t 
> necessarily mandate confidentiality.
> >
> > I still don't understand this part. What do "as a default" and
> > "authentication the minimum" exactly mean? What information needs to
> > be encrypted? Everything? The first octet cannot be encrypted to allow
> > detection of NTPv5 packets on the port 123.

This is an interesting point.
Talking confidentiality can quickly get one to talk about masking the 
subject of conversation - and with synchronization, there is a very clear 
divide, where you can either 1) have good synchronization performance, 
because messages and timestamping are treated with urgency, OR 2) have the 
conversation not be recognizable as a synchronization exchange.
I suspect NTP/any sync protocol will always have to be treated a little 
bit differently where aspects of confidentiality are concerned.
With NTP in particular, yeah, there is even current practice that 
explicitly demands that packets be recognizable as NTP packets.

> > For NTPv5 to be successful in replacing NTPv4, I think it needs to
> > support no authentication, symmetric keys and NTS.
> >
> >> This section in particular could probably use some editing and 
> clarification to better explain this [1] as we?ll likely need 
> consensus calls made.
> >>
> >>> 2. I think that it is better to allow leap smearing and make it 
> a visible part of the protocol than to pretend it is not going to 
> happen.  On this topic I think that Miroslav?s proposal was more 
> realistic.  Data center network architects tell me they definitely 
> plan to continue to do leap smearing.
> >>
> >> In other use cases such as publicly accessible NTP, leap smearing
> has effectively fragmented the pools of services a given host can 
> use as mixing smeared and non-smeared services is not a good idea, 
> in addition to the start/end and cadence of smearing being 
> inconsistent between providers [2]. I think that having a ?linear, 
> monotonic timescale? and leap smearing together are contradictory 
> and so having smearing in the wire format would requiring changing 
> that. My proposal doesn?t prevent smearing of a clock being 
> synchronised, it?s about removing the smear from the wire.
> >
> > They can be supported both as different timescales, server responding
> > in the one that the client has requested.
> >
> > If you don't allow leap smearing in NTPv5 at all, I suspect people
> > will either stick to NTPv4, missing the important improvements in
> > NTPv5, or ignore the specification and use a leap-smeared version of
> > NTPv5 anyway.
> >
> > Same for UTC vs TAI.
> 
> Many National Metrology Instituts (NMI) are using NTP to disseminate
> the legal time, which always is based on UTC. I suppose NMIs will 
> appreciate if NTPv5 servers will have the option to disseminate UTC.

Currently being employed in PTB's actual time dissemination working group, 
I can 100% attest to this.
All of my colleagues and superiors that I've ever talked to about this 
were shocked and appalled to learn that the WG was considering anything 
other than UTC as the basis for dissemination.

In that vein, I'm also supposed to communicate that the whole issue might 
become moot "soon", since leap seconds might just be removed as a thing 
that happens in UTC.
I'm just not sure how that relates to the timeframe for a possible NTPv5 
RFC release...

> >
> > It seems we need to agree on some very high level goals for NTPv5. Is
> > it supposed to replace most NTPv4 use cases? Is it supposed to be
> > implementable on current operating systems?
> >
> > -- 
> > Miroslav Lichvar
> >
> > _______________________________________________
> > ntp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ntp
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp