Minutes interim-2019-ntp-01: Tue 16:30
minutes-interim-2019-ntp-01-201902121630-01

The Network Time Protocol (ntp) Working Group virtual interim meeting
Date: Tuesday 12 February 2019 from 16:30 to 18:30 UTC.  



Participants:

Watson Ladd, Aanchal Malhotra, Steve Sullivan, Kristof Teichel, 
Danny Mayer, Marcus Dansarie, Sam Weiler, Thomas Peterson, Steve Guendert, 
Tal Mizrahi, Martin Langer, Dieter Sibold, Ragnar Sundblad, Rich Salz,
Christer Weinigel, Karen O'Donoghue, Miroslav Lichvar, Harlan Stenn, 
Denis Reilly

Beginning at 8:30 AM pacific with a minute or two for people to join.

Minutes taker: Watson Ladd
No objections to recording.

Administrative agenda bashing.

Chair slides up, post NTS security changed to roughtime. Materials
include Notewell.
https://datatracker.ietf.org/meeting/interim-2019-ntp-01/session/ntp

No other bashing.

TICTOC quick document status.

Karen: Beyond pleased to report YANG module is in RFC editor queue.
Enterprise profile needs to be done. Issues with referencing to IEEE
solved, will be smoother hopefully for enterprise. Nits cleared and
then submit revised version. General thought is that wraps up TICTOC
and remaining time in NTP.

NTP Quick Doc status:

Karen: Beyond excited to report MAC doc has cleared ISEG and is now in
the publication phase, in RFC editor queue. Second document is the
BCP, 1 DISCUSS left from EKR. Suresh (sp) will be cleared by end of
week, move to editor queue. BCP took a lot longer then expected.

A couple other queued up for ISEG.

Next: NTS

Karen: last spoken single paragraph edited,

Danny: round of applause.

Dieter: Update done, content can be spoken to by Marcus or Kristoff.

Marcus: here with Ragnus and Krister. We're done with the paragraph.

Karen: issue resolved, another question, discussion on mailing list.

Kristoff: Everything seems resolved.

Marcus: Impression is everyone is happy in 16. Concern about encoding
of addresses (i18n again) Would like discussion of it. We need to
handle this in some way

Christer: I raised a few issues, the one that is really important is %
encoding URI, really painful because character encoding not specified.
Better to say must be ASCII. Use IDNA. It will work, won't take away
functionality, simplifies things.

Karen: not in the draft yet. Do we have rough agreement on the
solutions? Can we incorporate?

Danny: why ASCII?

Marcus: Encoding not specified with % encoding. Unicode codepoint then
IDNA because DNS. Having to do all that is painful.

Marcus: submit PR, get it fixed.

Dieter: supports proposal for sending PR. After fix, should send.

Karen: sooner is better. Can take a while to go through ISEG. Krister,
PR, then Dieter update and submit to ISEG.

Danny: Can we obsolute 5906?

Karen: not a full replacement. How to move NTP to a full standard and
clear up docs. Would like to see 5906 removed. Other thing is to move
to historic.

Planning for NTS interop:

Another hackathon in Prauge, before IETF 104. Anyone at all interested
strongly encourage to try to participate. Kind of tough to do remote,
have done it. Most of Swedish contingent did it. Martin, Dieter,
Aanchal might be there. Mailing list to coordinate. Bit of
conversation and facilitate implementation. Mailing list set up, not
sending annoucement.

Anything else in hackathon for NTS?

Anything on NTS in general?

NTF implementation status.

Steve: no update. Trying to get Harlan online. Heard from Richard. 
Let's see if I can get update.

Karen: hackathon seperate registration. Is open. Registration for IETF
definitely open. Hackathon wiki listing all projects. NTS is on list.
Depending on who is interested could set up some infrastructure.
Previous years an Etherpad. How to best facilitate can move to
Hackathon planning list.

REFID updates:

Don't know anything to report. Harlan not on call. Table and come back.

Interleaved: conversations

Miroslav: several comments after meeting, suggestion to specify
followup for client server so server could avoid client specific
state. fundamentally different solution. So it should be in other
document. Also has problem that it enables traffic amplification.
Better not to specify at all. Comment that references should be moved
fixed in Git. Another one about problem with NAT. Already addressed
with a statment about server times being unique, if not good enough
let me know, most important is intention... implementations that might
accidentally send requests in interleaved that can't get responses
from interleaved. Selection not ideal, don't think it's brittle.
Extension field increases delay not compatible

Watson: Why not?

Miroslave: currently client sending interleaved mode gets basic back.
extension makes packet longer. Different measurement then in basic
mode. Basically clock filter could drop interleaved mode because the
delay is longer. Basic idea is basic and interleaved could be used at
same time, fallback should happen only when packet loss or server lost
timestamp.

Watson:  oh its that broken. I'll just accept that and be sad.

Miroslav: can't use extensions. Most popular implementation doesn't do
this. Anyway analyzing 1 TB of data for interleaved to see how
currently used. As expected used very rarely 1 ppm doesn't look like
any clients accidentally implement interleaved requests, a few
instances of the older NTPsec which removed support for interleaved
responses sending requests. What should we do about this? Avoid
completely breaking by requiring server use each time stamp only once.
Advantage is conforming clients will get a response in the basic mode
when there is a real packet loss. Question is do we care about this?
any guidelines about breaking implementations that don't follow
current spec. Not sure what to do.

Danny: Can't force em

Miroslav: do we go out out of way to fix it for them

Danny: Some conversation about unknown extension fields. Should ignore
them or drop whole thing.

Miroslav: currently don't use any.

Danny: preculiar situation. Not sure how we should handle it. May be
some security issues with interleaved.

Miroslav: pointers?

Danny: No. Discussion made me think.

Harlan joins meeting. Is sorry he is late.

Karen: Miroslav: question was guidence. Sure there is far amount of
it. Haven't done good job of maintenance to start with. Hope in 2019.
Need to add new functionality. Do think we care about this. Not
something a lot of people would use but is useful. A lot of mailing
list traffic on it.

Karen: did nice summary of issues. Can you summarize on mailing list?

Watson: can we fix this extensions?

Danny: extension fields just bad, people not handling.

Watson: In TLS clients fall back, eventually stopped. Real pain, took
years to end.  Security issue. Clients would fall back if things
didn't work.

Danny: with NTS set up the connection then use whatever you need. So
interleave isn't involved.

Karen: Right way forward is to clarify issues on mailing list. See if
we can get WG consensus on the individual questions. At highest levels
agree that not being able to use extension fields to extend protocol
seems odd. Anyway, any other conversation, questions on this?
Capability to do it.

Harlan: what is the apparent problem with extension fields?

Miroslav repeats: The issue was that in interleaved mode we wouldn't
want to use an extension field because it would make packets longer
therefore delay is longer and problems in filtering. Other issue is
incompatibility with servers. Currently will nicely fallback.
Suggestion to use extension field. Either to exchange transmit or to
detect support. One issue is current servers don't support unknown
extension fields meaning they don't respond correctly the other is
that if and how to use it in the interleaved mode.

Harlan: got proposals on everything and assuming there is a good
reason why people aren't looking at that.

Danny: broken server that doesn't understand extension field doesn't
mean we shouldn't use it. Can't fix everything. Shouldn't say we
shouldn't use it because X doesnt support it.

Karen: Miroslav fill in open issues and questions for WG or next step.

Harlan: extended information proposal out there. Includes bit for
interleave mode.

Miroslav: is it that I can use or am currently using?

Miroslav: can see from the timestamps.

Harlan: Not saying you can't. I'm saying there is a bit.

Miroslav: how do you detect?

Harlan: I-DO for that. Currently not a fan of client-server interleave
because of state on the server.

Miroslav: followup message allows amplification. No way around it.

Harlan: I-DO can do it. Not lots of precision unless you have a very
accurate clock and high precision timestamps

Miroslav: hardware timestamp supported. Common these days.

Harlan: then client server negotiation can work with I-DO. If can't
detect with timestamps then extended information. Not sure what issue
is.

Miroslav: Protocol works fine. Trouble is there is a NTPsec version
had to remove support, sends requests in interleaved mode, not able to
support responses. Older release

Client will experience packet loss or fail association.

Danny: We can't fix that. If not following broken. Don't think we
should spend time on working around that.

Miroslav: basically what I was asking.

Karen: anything else?

Sam Weiler: deeper dive into I-DO or extended information draft.

Karen: can do that. Thing is there the extension field
doc that is a dead working group doc. Last guidance was invididual
extensions compatible with 7822 could be consider.

Sam: not sure if responsive. Would it help the working group. As in do
people understand them?

Karen: we could dig in in more depth if you like. Is that responsive?

Crickets

Sam: move on.

Karen: we will see what we can do about extension field

Karen: Client data minimization. Is Daniel on the call?

Issues need to move forward with that one. Seperate note to summarize
for group. 

Aanchal hasn't talked to Daniel. At last virtual meeting don't think
there was followup. Harlan and Aanchal were to summarize

Karen: summarized results as far as 1 objection, 1 no clear statement,
some no objections with comments

Next document that we have is YANG data module. This has gone through
YANG doctors, read for WGLC, authors not on call.

Will send out for WGLC.

Listed: other WG docs. Part of what we need to do is we have a whole
bunch of individual submissions to triage. Agenda, welcome for
requests, got none. Suggest people look at related ids and see how to
move forward with some of these docs. Next thing was next steps and we
got request to talk about Roughtime.

Aanchal: submitted draft, got comments. Can summarize what its about.
Have gotten comments to address. Discussed, haven't yet updated.

Roughtime protocol: rought time synchronization but is useful in
various context. Main difference is that it provides third party
evidence of misbehavior of a server, which client can prove the server
misbehaved. Main advantage of roughtime. Server signs response,
details in draft. Sounds like any other protocol which also uses MAC,
but roughtime uses public key signatures required for functionality so
can verify. Now were various issues and comments. One of the concerns
is around leap second or how to implement. Currently smearing,

Marcus: implementation appears to work. Three more nits. If i can add,
Aanchal motivated begining use. Like to add main advantage is
application that can't set clock. Can use roughtime to see how wrong,
and can adapt sense of time. See that this could be used in browsers
to validate certs.

Aanchal: IOT

Marcus: don't see this as a competitor. NTP and NTS different role
from roughtime.

Aanchal: not replacement

Danny: NTP can

Harlan: NTP and POSIX don't set time backwards, slow clock down. Issue
isn't with UTC it's with POSIX.

Watson: is linux mainline broken?

Mirsolv: Can use own timescale. Suggesting can be used in parallel to improve

Watson: Agree

Miroslv: Can use interleaved mode to recover.

Watson: applications we're thinking of don't have that tight a need for time bad.

Sam: What about live PKI?

Watson: update files

Marcus: publish JSON file in existing format on HTTPS website. Or can
do what cloudflare does and have public certificate in DNS.

Sam: Two different models

Marcus: two different suggestion.

Sam: part of the system, worth contemplating, affects analysis.

Harlan: still chicken or egg.

Watson/Aanchal: not quite, can update. Original proposal for updateable devices

Marcus: furthermore, eventually anchor trust

Watson/Aanchal: individual

Rich: First time to include a config file will win.

Marcus: such a file with 5 servers.

Rich: overlap of trust store, 95%

Watson: not same incentives as PKI.

Marcus: and again don't think we have to solve maybe not at all.

Nicholas Marcus: Systemic decisions to make on the list

Aanchal: we knew, wanted to make sure the draft got here. Would love
suggestions.

Important to address

Karen: important issues. Need to address, 5-6 weeks before meeting can
plan update.

Watson: Drop dead date?

Rich: March 16 on the order, it's March 9th

Karen: will get back.

10 min to hour, at that have have operability going, andminstrative
stuff, last stuff. AOB?

Denis: ISPCS

Denis: ISPCS held in Portland Oregon Sept 22. Last year had it at
CERN. Even though ISPCS is forum for PTP papers, conference could have
good NTP based papers, charter is clock synch over networks in
general. I'm telling you because I'm a cochair. Want good papers
submitted. More convenient for all West coast people. ispcs.org

Karen: Rumors about about NTS paper submitted. Rough idea a bit late
doing the hackathon has been very helpful for focusing and progressing
WG efforts, one in July. Considering Nov because Singapore is tougher.
Hard to get people to. Keep that in mind. Don't have to limit to NTS,
would be helpful to look at other things and progress. Last thing 11
March is cutoff for IDs for IETF. Feel free not to wait, 22 Feb. This
meeting was focused, so some outstanding requests. Datatracker for NTP
working, before extension field if we had a side meeting and got
traffic on mailing list to revisit these. About it. Would like Harlan,
Sam, to coordinate OOB and be prepared coming into Prauge to discuss
them.

9:55 final remarks.

Harlan: did we discuss the BCP

Aanchal: send out mail about hackathon. Just wanted to confirm.

Karen will preenroll a bunch of us, can unsubscribe.

Meeting wraps with 30 min to spare.