NTP WG Meeting, IETF 110

NTP WG Meeting DRAFT Agenda
IETF 110
Tuesday 9 March 2021 - 16:00 UTC
Presentation materials: https://datatracker.ietf.org/meeting/110/session/ntp

Chairs: Karen O'Donoghue, Dieter Sibold\
Minutes: D. Sibold

Administrative (Chairs)

Presenter: Karen O'Donoghue\
Slides: https://datatracker.ietf.org/meeting/110/materials/slides-110-ntp-ntp-chair-slides-00

• Note well was presented
• Agenda was presented
• Agenda bashing: nothing proposed

Document status

• Command Mode 6 lost in a shuffle, one remaining issue

• Submitted to IESG for Publication. New draf version's have been submitted

• Port randomization on its way through IESG

• Interleaved and ticktock ready to submit, will happen right after IETF

• PTP Enterprise Profile is ready for IESG, will happen after IETF

Alternative Port

Presenter: Miroslav\
Slides: no slides

Discussion

• new version submitted. No significant changes.
• Comments from list addresssed
• Ready for WGLC
• Karen: Will call after meeting

Summary

WGLC will be issued after IETF

Update Registries

Presenter: Rich Salz\
Slides: no Slides

Discussion

• Rich: WG adoption
• Went through registries, pulled them all out, wrote them up, even implied
• Will be an issue for discussion with NTS registry partitioning
• Reminiscent of BSD reserved ports
• IANA looked it over to make sure it modernized everything
• Short doc
• Marcus Dansarie: Makes sense to me! Missing motivation for policies such as specification required. No problem with picking it, just would like a few sentences why.
• Rich: SGTM. Put in because of experience being a Designated Expert
• Yaakov: If adopted RFC only IANA considerations section?
• Rich: yes. Describes, gives a summary. So if someone hadn't done all the reading would give chance to figure it out.
• Daniel Franke: Can do without a draft, but think informational RFC was to go.
• Yaakov: First section to explain what to do. Just rearrange what's there.
• Rich: SGTM

Summary

• Call for adoption will be initiated

Chronos

Presenter: Neta Schiff\
Slides: https://datatracker.ietf.org/meeting/110/materials/slides-110-ntp-chronos-a-secure-selection-and-filtering-mechanism-for-the-network-time-protocol-00

Discussion

• Attacker control of fraction in the pool
• Client has proveable security
• Backwards compatability
• Low computational overhead
• Rely on many servers
• Not in all regions
• Heirarchy. Attacker only needs to control a few servers.
• 20 servers in germany, 52% of time servers in the pool
• 44 in North America, sufficient for shifting time of 14% in the region
• Small subset is powerful
• Suggest maintaining a trusted pool of Ananke
• Independent servers stratum 1, reputable, audited
• 100s for security
• Geo dispersed.
• Two process
• Primary default NTP v4 process
• Watchdog synchronizes with Ananke pool
• If primary too far from watchdog, stop and set watchdog pool
• Ex-region doesn't hurt much
• Only under attack does offset start to rise. Ananke stops the time shift
• Load balancing: low query rate to Ananke
• Showed attack, quantified it
• -02 updated watchdog and mechanism
• Next Ananke
• Watson: Once we have this deployment effort, why not NTS and Roughtime?
• We'll take it to list

Summary

Roughtime

Presenter: Watson Ladd\
Slides: https://datatracker.ietf.org/meeting/110/materials/slides-110-ntp-roughtime-00

Discussion

• draft -03 will be interop, as -04 has no wire format changes
• ecosystem-00 includes checks and trust anchors
• ... and has much more work to do
• Servers do not need to make any changes if this specification advances
• Other changes include Marcus as coauthor
• Possible typos or errors
• No opposition to adopt these documents

Summary

Call for adoption

Date and Time on the Internet

Presenter: Ujjwal Sharma\
Slides: https://datatracker.ietf.org/meeting/110/materials/slides-110-ntp-date-and-time-on-the-internet-00

Discussion

• Came from dispatch
• Format for dates and times
• Solved problem
• ECMA 39 Javascript
• Temporal
• Timezones and calandars in date model
• RFC 3339 as base
• Problem with Calendars is to include during persistence
• Human timezone in addition to offset and instant
• What is human timezone?
• Format wasn't standardized
• Calendars, numbering system
• Process for keys and values
• Add a calendar
• Watson: What about calendars that change the day boundary?
• Ujjwal: depends on usage, instance remained the time
• Carsten: Different applications. One bucket messy
• Carsten: we care about time scales, not nonphysical input
• Carsten: Plan time: Christmas 2022. Don't know about DST!
• Carsten: the more you go in the more complicated
• Carsten: Remembered time! e.g. ides of march
• Carsten: Need to know which wins.
• Ujjwal: Concerns are valid. Current draft doesn't work with planned time. Just like 3359 works with instants, addition for more metadata. Similar objects and information from stamp to relay context. Not other way around.
• Ujjwal: interest in planned time.
• Ira: important to correlate work with Carsten and others in CBOR

Summary

NTS for PTP

Presenter: Doug Arnold\
Slides: https://datatracker.ietf.org/meeting/110/materials/slides-110-ntp-network-time-security-for-ptp-00

Discussion

• People want secure PTP
• 1588-2019 Message extension with authentication TLV for message protection
• Little bit of key management
• GDOI and TESLA discussed
• TLS already there, NTP-NTS there, let's implement
• Lots of PTP NTP differences
• Multicast, on-path support.
• Message rates high. 128 Sync/second
• Unicast most like NTP
• PTP Grandmasters keep state
• Proposal: Multicast get group key from NTS-KE server
• NTS for PTP Unicast: ticket sent from NTS-KE server to client with key
• Cyclic update for all security information at server.
• Auth TLV for time messages
• NTS for NTP in IEEE, also chared by Karen
• Would like to move here, make IETF RFC
• More security expertise, we know NTS, want to keep coordination.
• Daniel Franke: In multicast, group keying, clients trust each other. Trusting switches and routers. What is left as the threat model?
• Doug: Someone who gains access at PHY layer. Best master clock algorithm, self proclaimed.
• Daniel Franke: permissioning clients?
• Doug: yes
• Has been used in real networks; GDOI in the Power grid securing GOOSE
• Daniel: not challenging usage. What's the goal? Compliance talisman or actual threat?
• Daniel: PTP model forces a lot of tradeoffs. With less trust gets to NTP. No crypto will save you from this.
• Doug: NTP can detect liars. In PTP not how it's usually done. Network access for an announcing grandmaster is a problem.
• Unicast case can be more like NTS for NTP. Lots of networks with unicast, no onpath support. More e2e highly secured.
• Daniel: Not clear that points on spectrum for NTP and unsecure PTP where this works
• Dennis: Securing time time itself is not what's being secured. Really associations. Focus is on secure PTP, making sure no clients attach to unauthorized masters. Partipation as a client not damage. That will be the focus. Best master clock not security in mind.
• Kristof: PTP not in stone. More people over long lines, scenarios not used before. Futureproofing smart to think about. Not in controlled networks necessarily
• Doug: good point. Why we have two different modes.
• Karen: Thanks Doug for pinch hitting.
• Doug: 00 draft posted, update coming. Already counterproposal on some details. We'll discuss

NTP v5 discussion

NTP v5 discussion was structured into thee parts:

• NTPv5 requirement's draft presented by James
• Draft of a NTPv5 specification presented by Miroslav
• NTPv5 Next Steps by Doug

NTP v5 Requirements

Presenter: James Gruessing
Slides: https://datatracker.ietf.org/meeting/110/materials/slides-110-ntp-ntpv5-requirements-01

Discussion

• Centralize ideas
• Get consensus on difficult points
• A few editorial changes
• New linear timescale
• UTC and TAI
• Steering separated
• Auth and Confidentiality
• Backwards compat
• Extensibity and anti-ossification
• Rate limiting, DDoS, NAT, threat model
• Should we adopt? What process for protocol design?
• Yaakov: Work was done at start of TICTOC, ITP suppost to be Next NTP, see if it's of use
• James: Thanks! Was unaware, will read it
• Doug: helpful in development to have document go forward. Lots of ideas. Agreeing on requirements can reign in the discussion.
• Daniel: Something of this shape forward in some form, not sure ID advancement needed. Grumble every time I review one for archival value reasons once spec adopted. Maybe in the wiki instead?
• Karen: Just had counterexample where draft 13 years ago useful. Some archival value
• Yaakov: separating steering from protocol. One discussion at time were these parameters in the packet because client server not master slave architecture. Everyone realized part of the issue. Interesting if separation possible. Protocol not hand in hand with stabilization even when pure client server.
• This should be discussed in the mailing list

NTPv5 draft proposal

Presenter: Miroslav
Slides: no Slides

Discussion

• New version, concept not changed
• Mostly like NTP
• Minimal changes to address issues we're set on addressing
• Maybe not given discussion.
• No protocol changes, text improvements. Full description of correction field. New section on measurement modes. Still lots missing to make full description. Need those requirements to make progress
• Clear some people want something very different
• Need to agree
• Karen: Need contributions to drive work. What do implementors want? What do vendors want?
• Yaakov: Looks solid
• Doug: Some of the other things people want to do. Real virtue is flexibility here. Can get time over public internet from pool. Also niche application. NTP packets not rest of NTP.
• Watson: As vendor, six of one, half dozen of the other. Is frequency separated helpful?
• Miroslav: Seems like need for time and frequency error minimization need to transfer both. Don't think this should be in the draft of protocol. Just timestamps. Up to implementation to control. Goal to minimize both time and frequency error.
• In NTP v4 PLL/FLL works doesn't always. People need something else in some cases. Specification shouldn't prejudge.
• Daniel: before adoption, contention about in half. Should NTPv5 be unauthed? Get consensus call before we do anything else. Real blocker in basic things with wire format.
• Yaakov: Any requirements doc, discussion of how you can exploit you might get frequency from other source (sync-E, etc.) worth capturing.
• James: Requirements in doc not set in stone, just collection. WG can have different view if it has consensus.
• James: Call for adoption not a call for security, just for a document
• Karen: might need to address answer in requirements
• Carsten: Leap smearing. Convergence on right way to do it?
• Daniel: Sort of. Google calls standard linear smear 24 hours linear noon to noon. This WG has more power to make actual convergence.
• Carsten: Actively pursued or just idea?
• Karen: I have scars from this
• Carsten: wondering if I haven't missed something.
• Carsten: CBOR?
• Doug: Enough people who work for large companies want leap smearing. Going to happen. Justification easier to mess up time than get database code to be correct.
• Daniel: No controversy on that. What we need to address is what NTP should do on the wire vs client OS?
• Doug: Think in Miroslav makes smearing visible. Should be in v5.
• Daniel: Packets should carry all necessary info to perform leap smear. No smeared timestamps.
• Yaakov: +1 to no wire smear
• Harlan: Expecting clients to handle leap smearing is naive. Uses for smeared time in NTP timestamp.
• Yaakov: Terrible in others
• Harlan: Policy locally. Smearing is mechanism.
• Watson: Huge mess if you smear and implement V5. Need to work with OS
• Harlan: Need to communicate the policy over the smearing. Trivial ways to make sure that time you give is smeared based on what they tell you. Doesn't have to be complicated. Over the last several years not that big a deal.
• Daniel: Configuration of clients sounds like DHCP is what you want.
• Harlan: need to update software.
• Doug: Right way for v5 to respond to v4 request is with NTP v4 response. If not, drop.
• Karen: One more presentaton!

Regarding NTPv5 (Key Issues, way forward)

Presenter: Doug Arnold
Slides: https://datatracker.ietf.org/meeting/110/materials/slides-110-ntp-key-issues-to-be-resolved-00

Discussion

• Why v5? accuracy, leap seconds, simplify, move to client server mode
• Two incomplete proposals, imperfect alignment
• Improved accuracy: certain applications. 50ns via NTP!
• High message rates. Different algorithms: lucky packet
• Do pretty well
• Miroslav does have on path support that can help with these cases
• One subnet
• Flexibility: Allow high resolution algorithms. Allow chronos
• Can provide outline of how they work
• Mandatory security: Faster adoption! Might work against niches, but probably different versions.
• Lets do TAI not GPS
• But everyone wants UTC
• Some niche people want UT1
• Unicast only: makes securing easier most popular
• Need to make a decision on them
• Carsten: Can outsource to COSE for v5
• Doug: Lots of discussion. And if they aren't familiar with timing they say things that make no sense. Time is a signal. Lots of little differences.
• Carsten: Can get format from COSE
• Doug: agreed
• Denis: Lots of leap second, security mandatory. Without rehashing consider NTPv5 different recs for servers on broader internet for servers on customer closed network. Stronger security in closed network.
• Watson: Not a good idea. More and more networks are the Internet.
• James: More insecurity when saying this
• Harlan: Still use case on networks for people not to use security on every packet. Not interesting, not appropriate for all use case. Don't change policy into mechanism.

Chartering

• Presentated Karen
• Defer to virtual interim. Dieter rought draft to discuss

AOB

• Daniel Franke: Byztime.
• In prod. Don't care about drift, just worst case. High quality. Independent stream experimental. If significant interest can purse something else.
• Interested in hearing if you use it or have applications.
• Karen: Two virtual interims before. April 13 or April 20th. Major conflicts to Dieter. Much to do after meeting.
• Harlan: 12-16 is ITU, Two weeks