Minutes for NTP at IETF-93
minutes-93-ntp-1

ÿþ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.