Joint TICTOC and NTP WG Meeting - IETF 90 - Totonto Monday July 21, 2014 Morning Session I 0900-1130 Chairs: Karen O’Donoghue and Yaakov (J) Stein There were no objections to the proposed agenda (but not all the items were actually discussed in the same order as in the agenda). NTP WG Status: The NTP extension field document (draft-ietf-ntp-extension-field) has completed WGLC and is still awaiting PROTO write-up. NTP Network Time Security draft-ietf-ntp-network-time-security will be discussed today. There is a new editor for what was previously called draft-odonoghue-ntpv4-control. At the last meeting we agreed to work on a new NTP BCP (partially motivated by the NTP server attacks earlier this year) - there are volunteers willing to work on this, but additional help would be appreciated. Dieter presented updates to draft-ietf-ntp-network-time-security detailing the changes made in the latest revision (version 4) and the next steps planned (version 5). There were several changes from version 3 to 4. 2 suggested by Steve Bellovin were to use the client's certi cate instead of its public key in the cookie calculation, and the introduction of a nonce in the server cert message (against replay attack). Adopted Tal's suggestion to correlate transmit time stamp with nonce to avoid a spoofing attack. Also added was mitigation of spoofing attack on the cookie exchange, use of message IDs for all messages, and introduction of different server seeds for different hash algorithms. Also added an appendix on use of TESLA for the broadcast/multicast mode, and revised requirements on the hash algorithm (also suggested by Steven Bellovin). Version 5 will add CMS scheme for the message exchanges, and will merge association and certification messages. Consideration of DANE was left for a future version. Shahram: does this draft apply only to NTP or do we need another draft for PTP? Karen: I am chairing the security group in 1588, and we are still in the requirements stage. We are putting together possible approaches, and have not looked closely at using this technique. So far looking into using MACsec and IPsec, and two 1588-specific approaches based on TLVs. However, 1588 IS using the TICTOC security document for requirements. Doug: I am co-chairing 1588, and there is a very different mix of people there (industrial, power, etc.) So not clear what is going to happen. Yaakov: MACsec is hop-by-hop, how can it be used in a switched network? Doug: security is challenging, and more complex with multicasting, TCs, etc. So there has been a lot of dicussion on end-to-end vs. hop-by-hop. Karen: not using MACsec to secure PTP, just some requirements will be addressed (we solicit contributions on this). A single solution that addresses all requirements would be very heavy-weight, so we are looking for a toolkit. We would prefer re-using existing techniques (such as this work) as much as possible. Yaakov: Is the modeling work that led to discovery of 2 attacks going to be published? Dieter: Kristof is going to published these findings. Yaakov (to Karen and the WG): Should we create a PTP security solution in tictoc? Karen: This should be discussed in PTP Security working group. Once this document matures more, the 1588 group will revisit it. They may come back with change requests. Yaakov: Will version 5 be the final version? Dieter: There will be at least a version 6, but version 5 will be the basis for implementation. Karen: Dieter asked me to arrange more informal conversations with security experts (they will be advertised to the list). Karen: The NTP BCP document is looking for editors. This is a great opportunity for anyone who wants to start working at the IETF. Next the TICTOC WG session. The chairs reviewed the WG document status. IETF LC on draft-ietf-tictoc-security-requirements has concluded and is in the hands of the IESG. Tal just submitted an update that addresses all the comments (thanks Tal!) draft-ietf-tictoc-ptp-mib has completed WGLC and is still awaiting a PROTO write-up. Would be great if someone could help compile so that this could be noted on the PROTO writeup. Stewart: Everyone is moving to Yang, are MIBs still the right thing to do? Doug: The older more conservative industries will be doing MIBs for some time, and the IEEE 1588 PAR specifies an SNMP-compliant MIB. There are also tools to convert MIBs to other formats, such as Yang. Karen: This work started before the re-instating of the 1588 WG, and we took this work on. This MIB is already being used, and is the starting point for the 1588 management work, so we need to get it published. Going forward the 1588 group will continue this work. Greg Mirsky: The IESG statement was about writable MIBs, and this is a read-only MIB. TICTOC could survey the community to see if people are using read-write MIBs for 1588. We certainly should encourage anyone working on netconf for 1588 to bring the work to the IETF. Yaakov: When I asked multiple vendors a year ago how they were configuring 1588, most were using proprietary MIBs. This was one of the reasons we started with this work, at least for the subset it covers, and it could be the basis for extensions in other groups. It would be an accomplishment if people started using this standardized MIB instead of proprietary ones. Doug: Most customers only use MIBs for traps, small group use MIB for configuration. The 1588 WG intend extending this MIB to be read-write. Karen: This document has been around for a long tie, and we need to finish it. I would like to remind everyone that both IETF and IEEE are contribution-driven; over the years there have been many suggestions in the NTP WG that no-one actually worked on. So if anyone has suggestions and wants to work on them, then please do so (sorry for sounding grumpy). draft-ietf-tictoc-1588overmpls has completed 2 WG LCs. There were several respins. After the last version there were further comments, but they were minor and editorial. Yaakov will sit with the authors this week to clean up the document. The new version will be advertised to the list, but there not be another LC. draft-ietf-tictoc-ptp-enterprise-profile has completed WG LC, but the deadline for comments will be extended. It is on the agenda. draft-shpiner-multi-path-synchronization was discussed last time and accepted as experimental WG document. Yaakov sent out an email to the list on this. Please comment to the list week. Doug presented the Enterprise Profile draft. This is mostly for financial industry to register event times, to playback sequences of events, and to examine latencies to find out where they originate. None of the existing profiles are suitable for this application. The change from version 2 to version 3 was the format of the Announce Message TLV. This was changed to match the format adopted by Power Profile (IEEE C37.238) to add uniformity. The idea is to standardize this format for all profiles. All comments to TICTOC list have been addressed. Yaakov: I have some comments that I have not sent to the list. My major comment is the lack of a requirements section with MUST and MAY terms. The draft starts with a general explanation that the idea behind the profile is to eliminate multicasting because of the large number of endpoints. This leads one to believe that delay requests would be unicast, but then the next section confusingly talks about handling multicast delay requests. It would be appreciated if the draft said "delay requests SHOULD be unicast" or something similar. There are also some editorial nits (e.g., words leftover from previous versions). Doug: please post your comments. I should mention that this profile has been implemented before this draft. At the 1588 plugfest we discovered that vendors have implemented this for this type of customers. Yaakov: What was implemented - multicast SYNCs and unicast of delay request ? Doug: The implementations are "respond in kind" - if the request is unicast the response is unicast, but if multicast then multicast. This accomodates legacy equipment. Yaakov: That is exactly the type of statement I would like to see at the top of the draft. SHOULD unicast, but if legacy equipment then MAY multicast, in which case the response is multicast. Doug: Agreed. Brian: Is the IEEE TLV format a moving target, or has it been finalized. Doug: It's a moving target, and only a proposal (hasn't been voted on). But it is becoming a moving target that is harder to miss since with this change there are now 2 profiles with the same format. Brian: When will generic format be balloted ? Doug: A year and a half or two years out. Power profile is balloting now. Brian: I am concerned with 2 SDOs chasing each other. Karen: I will send an email to the list extending the LC for 2 weeks. Please send comments to even support to list. Doug presented the IEEE 1588 update. We have already discussed a lot of this. Email Doug or John Eidson if you want to get involved. There are presently 48 voting members and 5 subcommittees. One thing the upkeep (maintenance) subcommittee is working on is the IEEE SA's new OUI structure (more bits for organization ID) which unfortunately breaks an option for 1588 clockID creation. The architecture subcommittee is working on splitting PTP into media independent and dependent layers (and many media already have built-in time transfer mechanisms). So long term 1588 will be the media independent part. The security subcommittee (already discussed) is looking into the IEC 61850 GOOSE message security mechanism, and TESLA. Yaakov: In TICTOC authentication of a client was not considered important. This is the case in 1588 as well? Doug: Listed as not high priority. However as a guy who works for a vendor of NTP servers, client authentication is used a lot in large IT infrastructures (usually by TACACS+ or RADIUS), mainly because everything is done that way. Management subcommittee working on SNMP compliant MIB (which is in PAR). After looking at several 1588 MIBs it was decided that the TICTOC one was the most versatile, and is the basis for this work. But now extending for profiles, perhaps by branches for profile-specific items. The High Accuracy work is based on the White Rabbit extensions to 1588 designed by CERN for the Large Hadron Collider (where 150 picosecond agreement between slave clocks is achieved). The nonstandard things are being added to 1588 as options, and include Synchronous Ethernet, calibration of asymmetries (cables and PHYs), and high resolution timestamps. They are presently discussing whether the L1 (syntonization) hierarchy needs to be same as the 1588 one. Yaakov: Is this being liaised to ITU? SyncE is being developed there. Doug: THis is separate work, but there is a lot of co-participation. In 1588 it was decided to use the white rabbit version of SyncE, and not the ITU version. Greg presented the Residence Time Measurement draft, which is being presented to the MPLS WG. The residence time is the time it takes a packet to traverse a node. MPLS packet delay measurement defined in RFC 6374 not useful for measuring residence time. The control plane consists of OSPF or IS-IS extensions for router capabilities and RSVP-TE for provisioning (both to be defined in later versions). This data plane uses the G-ACh with an 8-byte scratch pad for timestamp or correction field, and a TLV optionally containing a time distribution protocol packet (e.g., 1588 or NTP). Transit nodes operate on the scratch pad, but do not change the payload. Yaakov: Operates like a TC but updates the scratch pad? Greg: Yes. The offset of the scratch pad is known, so can be done by hardware. Yaakov: The control plane work is similar to the appendixes originally in the 1588ompls draft, so you can look at that. Shahram: and the appendixes were respun as separate drafts. Greg: Good idea. Sharam: How is the advantage as compared to the present 1588 over MPLS draft ? Greg: 1) Scratch pad is in a constant location. 2) Original packet is not altered by transit nodes. Stewart: The 2nd reason means simpler processing. Shahram: This does not solve the layer violation problem. Greg: It does since we use TTL expiration. If every node is RTM capable, then TTL is always 1. Yaakov: There is no correction to the 1588, only to the G-Ach packets. And the correction is at the end. Greg: If the timing packet is in the packet, then the scratch pad accumulates. Yaakov: Does the type indicate IP or the precise time distribution protocol ? Greg: It is the protocol. Yaakov: That is a layer violation in itself. Greg: We can discuss. Karen for Tal in the jabber room: It is unfortunately that we will have 2 methods for the same problem. It is still not too late to bridge the gap. Greg and Yaakov agreed that it IS to late. Yaakov: This is generic, while the present draft is an experimental draft for a specific subcase. Karen: There was discussion in the MPLS WG about producing a requirements document. Stewart: I can't answer for the MPLS WG, but this is generic, not DPI, can carry anything, and is of greater utility than the existing document. Shahram: If defining a new format, then why not add a timestamp or each transit node, rather than accumulate the corrections. This would allow isolating latency contributions. Greg: By manipulating TTLs you can achieve that. But interesting use case. Yaakov: What timestamp format will be used in the scratch pad? Greg: Similar to the 6374. Yaakov: So each transit node needs to know the format. Stewart: If the LSP is set up correctly, any necessary type conversions can be done. Greg: What Yaakov points out is the need to advertise the timestamp format each node supports, and then to homogeneously set up the path. Karen: For clarity purposes, this work is progrssing in the MPLS WG, and is brought here for information. Yaakov: We will talk with the MPLS WG chairs to coordinate. Yaakov mentioned that an email was sent to the TICTOC list regarding the proposal to form a new WG in the APP area called "Time Zone Data Distribution Service" (tzdist). This WG would be chartered to define a time zone data distribution protocol, and to extend CalDAV (RFC 4791) to allow using TZs "by reference".