Joint TICTOC and NTP WG Meeting
IETF 93 - Prague 
Monday July 20, 2015 Afternoon Session I
1300-1500 CEST (1100-1300 UTC) Athens/Barcelona room 

Chairs: 
Karen O’Donoghue (at the mike)
Yaakov (J) Stein (displaying slides and taking notes)


Agenda bashing
As traditional this is a joint NTP+TICTOC meeting.
We will cover the NTP WG first, and then TICTOC.


NTP WG Segment

NTP WG status 
* Two complementary drafts have completed WGLC and are awaiting PROTO write-up :
	draft-ietf-ntp-extension-field
	draft-ietf-ntp-checksum-trailer (question about status - experimental or standards track ?)
* We will hear today about three complementary NTP security drafts :
	draft-ietf-ntp-network-time-security-09 
	draft-ietf-ntp-cms-for-nts-message-04 
	draft-ietf-ntp-using-nts-for-ntp-01 
* Still looking for an editor for draft-odonoghue-ntpv4-control.
* We will hear today about the NTP BCP, and the NTP YANG model. 

Network Time Security (Dieter Sibold) 
Karen mentioned that the IEEE 1588 security committee is looking at these drafts.
Dieter provided history, scope, and relationships between the 3 drafts and other work.
There are 2 independent implementations for NTP unicast time request and response messages 
(no implementation for PTP or NTP multicast).
The major change in 09 draft is that the specific association and cookie messaging exchange 
based on CMS was moved to Appendix B, and only requirements were left in section 6. 
This specific exchange MUST be implemented, 
but alternative mechanisms (e.g., based on DTLS or DANE) MAY be used.
The following suggestions by Florian Weimer are under consideration and will require redrafting:
using a Photuris (RFC 2522) cookie in order to protect against DoS attacks,
clean separation between negotiation and time distributions phases,
and providing an RFC-5077-style opaque structure for session state.
Karen: Many of the usual participants are not here nor on-line due to the hour.
How many people are familiar with these drafts ? A fair number.
Question: What is the precise content of thse drafts? 
Dieter showed the relationship slide.
Question: how does this help against the recent NTP attacks?
Dieter: not in scope.
Karent: in scope of BCP draft.
Question (from someone from Ciena): The main draft is already in version 9.
When will these drafts be considered done? Security documents are never rock solid.
As a vendor we won't be able to implement this if it takes another 2 years.
Karen: We are a lot closer to something stable now, and the other 2 drafts are newer.
We needed implementation experience in order not to publish something not ready.
We expect to move on by the end of the year. Do you intend implementing? Answer: yes.
Question: This is a BCP? 
Karen: No, this is standards track. 
Autokey was published as informational, 
with the understanding that it would be replaced by something more acceptable to the IETF security community.
These drafts are that replacement.
We are hoping that some of this will be dual-use, i.e., also be adopted by IEEE 1588.
Questioner: IEEE is less interesting since it works slowly. 
Karen (humorously): Have you witnessed the NTP WG?
Dieter: NTF expects to finish implementaton by August or September.
Karen: The time has arrived for serious review.
Y(J)S: Is appendix B also mature enough?
Dieter: yes, this is the same material from previous drafts.
Sam Weiler: Given maturity, shouldn't we ask for comments as part of WG LC process?
Karen: We want to process the three documents as a set. Dieter - are the other 2 ready?
Dieter: No. Sam: What is broken? Dieter: Need to finish consideration of comments discussed before.
Karen: We have started holding monthly telephone calls as virtual interim meetings, 
that would be the best forum for comments.

NTP BCP (Denis Reilly - remotely) 
Denis works for a vendor of NTP servers which helps its customers configure them, 
and is thus interested in this BCP.
The document is being developed using the NTP WG wiki (http://trac.tools.ietf.org/wg/ntp/trac/wiki/BcpOutline).
Contributors are invited to edit the wiki or by sending to the list.
An ID will be generated once there is more material; hope to have one by IETF-94.
Most of the present outline focuses on security issues, e.g., mode 6/7, 
Autokey (Harlan says best practice is "don't use"), use of pools, and example configurations.
There are also other ideas that have come up, but unless someone comes up with text,
they will be tabled in the interest of expediency.
Yaakov: I may be able to contribute text on virtual machines.
Karen: Our AD urgently requested this document over a year ago, 
so we should start moving to monthly calls. Can you have an ID out by August? 
Denis: Yes.
Karen: The key issues are mode 6/7 and pools of servers, and we should get these out as soon as possible.
Jared Mauch: I am with NTT, but in my spare time I run the OpenNTPProject 
which scans the Internet for OpenNTP servers.
This document should be very high priority, 
because the NTP attacks were the largest NTT ever saw on its network.
NTP went from 0.01% to 10% of the traffic, so that NTT ended up rate limiting NTP everywhere.
NTP configuration is not simple, and there isn't good documentation available.
Leif Johansson: Resist the urge to rat-hole this BCP. 
Publish something and rev it, otherwise it will take infinite time.
Karen: Agreed. Let's get the issues that are of most concern documented and out the door.
Denis: Please send contributions.
Yaakov to Jared: Are the attacks still on-going? Or have configurations been fixed?
Jared: Traffic volume has definitely gone down, 
but still part of blended attack portfolio of UDP-based protocols such as CHARGEN, SSDP (uPnP device discovery), SNMP, and NTP.
The attacks have also become more sophisticated, 
e.g., can use SSDP discovery to uncover all devices behind router 
and then make all of them participate in the attack, rather than just the router.
As a consequence US carriers frequently rate limit all UDP to 10% of traffic.
So lack of this BCP is contributing to filtering Internet and misclassifying traffic as garbage!
Yaakov: Including recognizably valid traffic such as VoIP? 
Jared: Vendors have not made it easy for operators to classify traffic.
Karen: This WG is a great place for newcomers to the IETF to learn how to participate.

YANG Data Model for NTP (draft-wu-ntp-ntp-cfg-01)
Karen: Did not receive slides or get confirmation that the authors would present today.
Eric Wu: We just updated this draft to take into account comments. 
It is not very different from the previous version.
There was another comment requesting to combine with RFC 7317 (YANG Data Model for System Management),
which already contains some NTP configuration, and we are considering this.
Karen: The comment requested to compare with RFC 7317 or merge with 7317?
Eric: We will compare, but do not intend merging. 7317 has only very simple NTP configuration. 
Karen: Has anyone compared this with the NTP MIB?
Eric: The draft has a section comparing with the MIB.
Karen: and is anyone planning to implement this?
Eric: In the future.
Karen: We never adopted this as a WG document. Do you still plan pursuing this work in the NTP WG?
Eric: Yes.

Karen: We hadn't intended discussing the NTP extended extensions draft. Are any of the authors here? (no...)
There has been a fair amount of discussion about this on the list.
The question is whether this is appropriate for NTPv4, or more suitable for a future version of NTP.
Strongly encourage to take a look.


TICTOC WG segment
 
TICTOC WG status
* Old news that draft-ietf-tictoc-security-requirements was published as RFC 7384.
* PTP MIB had minor changes made in preparation of PROTO write-up, with no content changes.
  It compiles.
* The 1588 over MPLS draft is holding on Yaakov to fix wordings, expect to be finished within a month or so.
  This will be published as an experimental RFC. 
  There is a new "residence time" draft in the MPLS WG that interested people should read.
* PTP enterprise profile is ready for WG LC, and will be sent to LC before a virtual interim meeting in August.
* draft-ietf-tictoc-multi-path-synchronization-02 in WG LC, and is planned as an experimental.
Sam: Tal in the jabber room says that the multi-path-synchronization draft has finished WG LC.
Karen: I am sure that Tal is right.
* We will hear now about the 1588 YANG model. 

Yang Data Model for IEEE 1588v2 (Yuanlong Jiang)
The 1588 MIB draft which is progressing here is limited to monitoring (reading) state of PTP clocks,
while draft-jlx-tictoc-1588v2-yang presents a YANG data model for both configuration and statistics.
It also provides validation and roll-back features, and multi-layer hierarchy,
making it a more attractive modeling language for 1588 networks,
while being compatible with the MIB for state retrieval.
Service providers find configuring and maintaining synchronization networks to be complex and time-consuming,
and require more flexible configuration capabilities, as well as discovering the current sync path,
monitoring for faults, and fault diagnosis.
Yaakov: What do you mean by "faulty path", is this end-to-end or are you isolating faults?
Yuanlong: We mean monitoring all the nodes along the path.
Yaakov: That's what I thought you meant. That's a completely different problem from what the MIB is addressing.
You are looking at many timing elements at the same time and monitoring the entire timing network.
For that you need a centralized timing performance server.
Yuanlong: The scope is wider than before, but that is the requirement.
Yaakov: At what level does the centralized server deal? Optical, Ethernet, IP? The fault may be at a lower layer!
Yuanlong: That is the complete picture, but for now we are working only on Ethernet and IP.
Continuing - There are relationships between this work and the ITU-T G.7711 information model (not yet ready), 
with IEEE 1588, and with the IETF generic YANG model.
The next step is to add more configuration capabilities. 
We would appreciate more reviews and welcome others to join the work.
Yaakov: Do you envision that a fault would trigger a YANG notification, 
or would the user notice a problem and then query?
Yuanlong: There will be 2 steps. 
First we continuously monitor all timing nodes, and then perform analysis on all that information.
If a link is down then all the downstream nodes will be faulty, 
and some intelligent processing will lead to identifying the root cause.
Yaakov: Who in the room has read the draft ? Several have.
This work is much more challenging and we need to understand more about how the processing will be done.
Karen: Is there any active coordination going on with the network management portion of IEEE 1588? 
Yuanlong: Not yet.
Karen: We can talk about this more.
Yaakov: There are now two YANG drafts, one for NTP and one for 1588. Is there any connection between them?
Yuanlong: We are from two different groups and don't see any connection.
Yaakov: In TICTOC we try to do as much as possible in common between NTP and 1588.
I am not saying that this is needed or advisable, just asking if someone has looked into it.
Yuanlong: I will discuss with the authors of the NTP YANG draft.
Karen: We need to investigate whether it makes sense, it's OK if it doesn't.

Quick update on IEEE 1588 work (Karen)
Doug usually gives the update, but is not here this time.
1588 is currently holding monthly calls and meeting f2f 4 times a year.
The next meeting is the week of August 24 in Noxville Tennessee. 
Work is ongoing in 5 committees:
1. high accuracy (based on CERN White Rabbit extensions) 
2. architecture (alignment 1588 and 802.1AS, and multi-master and multi-path questions)
3. upkeep (initially adressing requests for clarifications since publication of v2)
4. network management - the MIB was originally done here, since there was no work in the IEEE at the time.
While the NTP YANG work more obviously fits here, we need to consider where it makes sense to do the YANG work for 1588.
5. security WG - v2 Annex K is being replaced by a security section presently being developed.
The timing community is relatively small and hopefullly we can re-use the NTS work.

The only other TICTOC item is the enterprise profile, which is close to WG LC. 
There has not been an update since last time, so there no need to discuss.

Karen: Are there any further comments on TICTOC issues?  (None)

Finished 30 minutes ahead of schedule.