►
From YouTube: IETF108-NTP-20200731-1100
Description
NTP meeting session at IETF108
2020/07/31 1100
https://datatracker.ietf.org/meeting/108/proceedings/
A
A
A
A
A
A
A
A
If
you
wish
to
send
audio
so
that
at
the
top
you
see
you
have
your
name
and
then
below
that.
There's
a
white
bar
and
there
you'll
see
going
left
to
right.
You'll,
see
a
screen
request,
a
camera
request,
an
audio
request
and
then
the
fourth
one
on
the
far
right
is
audio
on
all
the
time.
So,
generally
speaking,
you
won't
be
doing
that
so
we'll
manage
the
queue
just
like
we
have
in
other
meetings
where
we've
had.
A
A
Oh
yeah
and
I've
been
also
been
reminded
that
there
are
tooltips
but
they're
over
to
the
right.
So
sometimes
you
don't
see
them
and
you
can
see
under
the
participant
you
can
see
who
the
participants
are
and
who's
in
the
queue
or
you
can
see
the
jabber
chat
room
and
if
you
are
monitoring
it's
it's
the
same
jabber.
It's
ntp,
the
ntp
room
at
jabra.ietf.org.
A
A
A
Oh,
that
the
the
other
thing
is
we,
we
aren't
gonna
get
a
jabber
scribe.
If,
if
you
don't
want
to
speak
at
the
mic,
just
put
mike
in
front
of
your
word
and
in
front
of
your
words
in
the
jabber
room
in
the
chat
room
and
we
will
catch
it,
the
I'll
be
monitoring
the
chat,
as
the
meeting
goes
and
ditra
will
be
managing
the
slides.
A
A
A
The
we
have
two
documents
in
the
rsc
editor
queue,
the
ntp
packet
time
stamps
and
the
nts
document
for
those
of
you
who
attended
the
plenary.
You
understand
that
there
is
a
bit
of
a
delay
in
the
rfc.
Editor
queue
right
now,
because
they
got
a
huge
dump
of
the
cluster
238
documents
all
at
the
same
time.
So
that
is
fine.
A
The
next
document
is
the
control,
the
command
mode,
6
messages
and
eric.
This
is
something
I
should
have
checked
with
you
before
the
meeting,
so
I'll
go
ahead
and
do
it
now.
Are
you
waiting
for
me
to
update
the
shepherd
or
am
I
waiting
for
you
on
something?
This
is
kind
of
an
embarrassing
question
at
this
hour,
but.
D
Well,
I'm
embarrassed
that
I
don't
know.
Actually
I
was
just
looking
at
that
actually
in
follow-up
and
it
says
that
there's,
like
you
know,
state
like
as
if
it
were
a
standards,
action
or
a
vgp
thing,
but
it's
it's
state
change
informational,
so
I
will
figure
out
what's
going
on
and
what
I
should
do
and
I'll
follow
up
with
the
with
you
guys.
A
B
A
A
A
E
A
F
C
Okay,
so
can
I
go
ahead
and
start
yes,
okay,
so
this
is
a.
This
draft
is
a
joint
work
with
neta,
danny
and
mikhail
or
from
the
hebrew
university,
and
this
draft
has
been
around
for
a
while,
but
in
the
current
version
of
the
draft
there
was
a
significant
change
that
we
want
to
present
today
and
we
want
to
hear
some
feedback
about
that
next
slide.
Please.
C
C
C
So
if
it
happens
that
two
of
these
four
servers
have
been
compromised
by
an
attacker,
that's
already
a
problem
in
ntp
today,
but
chronos
can
handle
that.
Okay,
so
that's
the
threat
that
we're
talking
about
generally
and
we're
assuming
that
attackers
either
have
access
to
an
ntp
server
or
they
have
access
to
the
path
between
the
client
and
the
server
okay,
a
man
in
the
middle
attacker.
So
each
of
these
cases
is
a
bit
different,
but
the
outcome
can
be
the
same
either
by
manipulating
the
ntp
messages
or
by
delaying
them.
C
Okay,
so
general
reminder
of
what
chronos
does
so.
First
of
all,
the
basic
thing
is
that
chronos
connects
to
a
very
large
number
of
servers,
just
when
I
say
connect
just
a
calibration
process
where
it
gains
access
to
a
large
set
of
servers,
let's
say
100
or
a
few
hundreds
of
servers,
but
in
each
poll
interval
only
a
small
subset
of
these
servers
are
chosen
and
pulled,
and
this
small
subset
can
be.
C
So
from
these
hundreds
of
servers
in
each
paw
interval,
we
choose-
let's
say
four
different
servers
and
then
in
each
poll
interval
based
on
these
few
servers
that
were
accessed,
the
client
performs
a
filtering
algorithm
which,
which
gets
gets
rid
of
false
stickers
and
also
does
a
kind
of
an
average
in
order
to
improve
the
precision
next
slide.
Please.
C
C
C
C
C
C
Please,
okay,
so
the
idea
is
that
both
of
them
run
in
parallel
and
in
each
pole
interval.
We
compare
the
result
of
the
the
clock
value
of
ntp
v4
to
the
clock
value
of
the
chronos
watchdog,
and,
if
that,
if
the
difference
between
these
two
clocks
exceeds
a
certain
threshold,
let's
say
a
few
tens
of
milliseconds
we're
assuming
we're
under
attack
and
since,
if
we
are
assuming
we're
under
attack,
in
that
case,
we
start
using
the
kronos
algorithm
rather
than
using
the
ntp
v4
algorithm.
C
C
So
what
are
the
next
steps?
First
of
all,
working
on
implementing
chronos
as
a
watchdog,
and
if
people
are
interested
to
implement
it,
chronos
will
be
happy
to
hear
about
that
and
we'll
be
happy
to
work
with
the
people
who
are
interested
in
that
we're
also
continuing
to
evaluate
the
performance
of
chronos
as
a
watchdog
and
we're
looking
for
feedback,
especially
about
the
current
version
of
the
draft
and
and
about
this
approach
of
using
chronos
as
a
watchdog.
C
C
It's
not
the
same,
but
it's
based
on
the
same
concepts.
You
know
the
the
concept
of
using
agreement.
Algorithms
are
have
been
well
established
for
30
or
40
years,
and
the
idea
is
that
you,
basically
you
take
the
top
third
and
the
bottom
third,
and
you
ignore
them.
You
only
take
the
middle
third
of
the
samples
and
then
you
do
some
kind
of
either
an
average
or
a
median
from
these
samples.
So
the
concept
is
not
identical
to
mtp,
but
it's
pretty
similar.
Okay
thanks.
G
D
G
A
A
And
tal,
if
maybe
you
or
neda,
could
send
a
reminder
to
the
mailing
list
along
with
a
pointer
to
the
document
and
ask
for
comments
and
also
any
any
feedback
on
folks
that
might
be
interested
in
implementing
it
sure,
yes,
yeah.
I
also
note
I
know
that
we
had
discussed
it
both
as
an
experimental
draft
and
as
an
informational
draft.
I
know
that
it's
currently
informational
and
depending
on
feedback
on
implementations,
we
might
want
to
think
about
what's
the
right
status.
A
A
A
F
H
A
A
A
A
A
A
A
B
I
I
So
the
the
idea
is
to
divide
ntp
v5
into
into
two
major
subsystems
which
I'm
calling
the
timing
engine
and
the
protocol
engine,
and
the
whole
point
is
to
allow
ntp
to
be
kind
of
set
up
for
specialized
applications
that
might
need
either
one
either
the
timing
engine
or
the
protein
call
engine
to
act
a
little
differently
than
it
does
for
the
general
purpose.
I
t
case.
I
And
yeah
so
examples
of
different
timing
engines
is
one
would
be
that's
very
precise,
maybe
for
financial
networks
and
one
that's
that's
just
for
general
id
setting.
You
know
log
file,
timestamp
timing
and
this
sort
of
thing,
security,
ticket,
timeout
and
examples
for
protocol
injuries
may
be
to
be
a
version
with
security
and
without
security.
I
I
I
And
here
there's
there's
two
possibilities:
it
could
be
software
time
stamps
from
an
operating
system
system
clock
that's
steered
or
it
could
be.
You
know
if
it's
a
hardware
time,
stamping
situation
where
you
have
a
counter
on
a
thigh
that
you
can
steer,
then
that
would
be
also
another
possibility
for
the
clock.
That's
being
steered.
I
I
I
Okay,
so
a
couple
notes
on
that
local
clock:
you
know
it
can
be
an
os
system
clock
and
can
be
securable
counter.
You
know
if
it's
a
kind
of
a
not
a
general
purpose-
hardware,
but
some
kind
of
specialized
thing.
Then
it
might
have
a
custom
hardware
clock,
for
example,
implemented
in
an
fpga
or
something
like
that.
I
I
I
I
I
If
there's
security,
that's
part
of
the
protocol,
so
that's
executed.
You
know
key
key
management
and
the
whole
bit
in
my
proposal.
The
protocol
engine
decides
exactly
when
to
send
packets
based
on
some
kind
of
average
packet
interval
packet
rate,
that's
determined
by
the
timing
engine,
so
the
timing
engine
might
say
I
want.
I
want
you
to
send
packets
to
this
server.
I
I
Okay
timing,
engine:
okay,
based
on
a
suggestion
I
got
on
the
email
reflector,
the
timing
engine
should
select
the
servers
to
receive
from
and
then
yeah.
As
as
I
look
into
what
all
the
timing
engine
does.
It
makes
total
sense
because
the
timing
engine
is
analyzing
the
different,
how
good
the
data
is
from
different
servers,
and
so
you
know,
for
example,
like
a
false
ticker
identification.
I
I
I
I
guess
if
it's
a
if
it's
a
server,
it
generates
information
about
its
reference
and
how
well
it
looks
tracking
the
reference.
Okay
next
slide,
please,
okay.
So
this
is
a
kind
of
a
look
at
the
the
interface
between
the
two
from
the
timing
engine.
We
get
a
list
of
target
server
ip
addresses
and
the
desired
average
packet
time
interval
for
each
server
from
the
protocol
engine.
I
If
one
of
those
servers
isn't
responding,
then
it
reports
that
back,
it's
that
has
to
happen
since
the
timing
engine
is
one
that's
selecting
them
from
from
some
left.
It
needs
to
know
which
ones
are
unavailable
and
then
every
time
a
packet
is
received,
there's
a
data
record
which
has
all
the
time
stamps
information
about
the
server.
If
it's
a
you
know,
this
is
from
the
client
view.
You
know
things
about
leap.
Second,
what's
the
stratus
of
the
server.
I
Security
on
off,
so
this
is
sort
of
the
client
view.
Actually,
I
need
to
generate
one
of
these
slides
for
the
server
view
as
well.
What
it
looks
like
because
then
that
information
on
the
on
the
timing,
all
this
information
on
stratum
and
leap.
Second,
that
goes
the
other
way
from
the
timing
engine
to
the
protocol
engine.
I
I
They
had
lots
of
good
questions
and
suggestions
they
so
they
helped
make
make
this
a
little
better,
but
not
don't
blame
them
for
the
things
that
are
still.
You
need
work,
that's
my
fault,
I'm!
I
would
like
to
draft
an
architecture
document
along
these
lines
and
I'm
look
if
anyone
wants
to
to
help
work
on
that.
Please
let
me
know
that's
my
email
address
and
that's
all
I
got
today
and
answer.
E
It
seems
to
me
this
is
about
a
design
of
a
server
and
client
that
would
be
recommended
right,
so
it
wouldn't
be
required,
like
anyone
would
be
free
to
implement
it
slightly
differently,
but
the
protocol
needs
to
be
specified
strictly.
So
is
that
supposed
to
be
separate
or
everything
in
one
document.
I
If
there's
going
to
be
more
than
one
version,
it
might
be
easier
to
have
separate
documents,
as
you
suggested.
I
think
you
know
having
a
protocol
document
that
says
you
know
this
is
the
structure
of
the
packet
and
and
the
general
ideas
about
the
sequence
and,
and
there
would
be
an
architecture
document
that
would
sort
of
explain
the
the
concept
and
defined
in
more
detail
than
I've
shown
today,
the
this
interface
between
the
two
and
then
another
document
that
would
be
the
timing.
Engine
description.
I
A
A
Standards
track
and
the
algorithms
might
be
informational,
but
again
we
don't
have
working
group
consensus.
We
haven't
actually
done
an
update
to
the
charter
to
even
cover
the
work
yet
so
this
is
really
a
these
are
preliminary
discussions,
so
I
I
would
appreciate
thoughts
on
what
the
plan
should
be
to
help
us,
formulate
them.
I
I
What
what
I've
seen
is
that
people
are
already
doing
this
with
ntp
v4
non-standard-
it's
not
described
anywhere
in
the
itf,
but
there
are
a
sort
of
proprietary
versions
of
ntp
for
niche
applications
and
the
one
that
comes
to
mind
is
financial,
I.t
and,
and
these
people
say:
oh
no,
we're
doing
ntp
and
I'm
like.
Well,
you
you
have
a
your
your
message
rates
and
your
clock,
control
filters
and
algorithms
are
are
different
than
what's
described
in
the
itf,
so
you're
kind
of
doing
a
non-standard
ntp,
but
but
they're
they're.
I
A
A
B
I
I
I
Yeah
I
mean
my
my
thought:
is
the
timestamps
come
either
from
an
operating
system,
clock
system
or
from
some
kind
of
hardware,
counter
that?
Oh,
you
can
access
through
a
driver
and
the
protocol
engine
should
just
be
able
to
pull
the
directly
when
it
needs
to
as
it's
constructing
a
packet
or
filling
those
fields
in
a
packet.
A
J
Yeah,
my
question
was
basically
about
precision,
time
protocol,
the
ieee,
1588
or
whatever
one
standard
it
was,
I
think,
had
us
down
to
fempro
seconds
precision,
which
is
a
little
bit
better
than
a
quarter
of
a
nanosecond.
I'm
just
curious:
if
we're
going
to
need
something
to
be
able
to
extend
to
sub
32-bit.
You
know
the
second
low-end
bits
for
the
protocol.
If
they're
going
to
be
having
ppp.
I
Reference,
you
know,
that's
a
good,
a
good
point
when
we
did
that
in
1588.
We
wanted
to
make
sure
that
we
had
enough
resolution
that
we
wouldn't
have
to
address
this
for
a
long
time
again-
and
this
was
in
anticipation
of
you-
know,
things
like
white
rabbit
ptp,
but
you
know
some
of
the
niche
applications
where
people
want
to
use
ntp
rather
than
ptp,
because
ntp
has
certain
properties
they
like
or
they're,
used
to
it.
J
I
J
Well,
yes,
I'm
just
suggesting
it
normally.
Ptp
requires
special
hardware,
latching
and
other
things.
It
gets
quite
tricky
to
do
that
over
the
ntp
protocol,
which
has
a
fair
amount
of
slop
in
it,
the
pol's
getting
us
down
to
maybe
a
microsecond
on
a
really
accurate
system,
but
I'm
just
curious
because
the
the
finance
industry
does
typically
want
to
make
sure
that
trades
happen.
I
I
K
Could
you
kill
me?
Yes,
thank
you
well
just
to
say
that
if
you
want
to
synchronize
in
one
network
I
mean
along
the
internet,
it's
quite
difficult
if
you
want
to
go
under
microseconds
because
traffic,
because
the
asymmetry
in
the
into
the
links,
the
connection
to
the
server
normally
asymmetrics,
and
this.
K
This
gives
you
a
problem
where
you,
perhaps
you
can
synchronize
frequency,
but
not
exactly
time
you
perhaps
you
you
got
a
very
low
frequencies
inclination
and
we
with
an
unknown
delta
time.
Okay,
if
you
do
this
in
some
network,
where
you
can
be
sure
that
the
path
go
and
the
forward
and
back
path
are
symmetric,
you
can
got
normally
very,
very
low,
very
low
number.
I.
D
L
D
K
L
I
I
I
There
tend
to
be
more
local,
smaller
networks
with
few
hubs
and
then
in
the
finance
case,
they
will
typically
have
you
know
two
or
three
hops
through
switches
that
are
the
fastest
ones,
that
money
can
buy,
30
loaded
with
small
packets.
Only,
and
so
in
that
kind
of
situation,
you
can
really
achieve
very
precise
time.
A
E
E
Yes,
you
have
any
comments
or
suggestions,
you
can
add
it
there
or
on
the
mailing
list,
and
also,
I
would
like
to
add
that
even
for
ptp
and
white
rabbit
they
have
just
reached
the
limits
of
the
quarter.
Second,
precision
that
ntp
is
using
so
going
below
that
one
quarter,
nanosecond
precision
is,
might
not
be
needed
in
near
future,
like
the
hardware
time
stamping
on
computer.
That's
typically
used
is
precise
to
maybe
hundreds
of
nanoseconds,
it's
difficult
to
calibrate
these
errors
out.
I
Well,
well,
I
would
would
say
that
you
know
it's.
Certainly
a
lot
of
trouble
to
get
down
you
know
below
microseconds
talk,
starting
talking
about
nanoseconds
or
even
below
nanosecond
is
a
lot
more
work
and
only
works
in.
You
know
kind
of
small
networks
that
are
sort
of
carefully
calibrated
and
all
this
sort
of
thing.
However,
you
know
that
again,
the
finance
community
has
what
I'm
hearing
from
them
are
two
things
one
is
we're
used
to
ntp.
We
like
at
least
for
some
some
people
in
the
finance
world.
I
They
like
it,
they
use
certain
aspects
of
ntp
that
are
not
available
in
ptp
and
but
now
they're
moving
to
refine
their
application
and
they
need
more
precision,
and
so
we
might
find
that
there
are.
There
are
some
niche
applications
that
really
are
going
to
want
to
do
things
like
cable
and
phi
calibration
and
and
have
have
a
very
you
know,
fine
resolution
for
time.
A
A
A
A
A
So,
if
there's
nothing
else
on
this,
thank
you
doug.
I'm
gonna
pop
you
out
of
the
queue
martin.
If
you
want
to
go
ahead
and
start
getting
in
the
queue
that
would
be
great
and
so
ditra
he
wants
to
sh.
Okay,
there
you
go
just
to
wrap
up
that
last
subject.
I
want
to
thank
marislaw
for
reminding
us
that
we
do
have
a
detailed
list
of
requirements
on
the
wiki.
F
A
H
H
H
Please:
okay,
perfect,
yeah,
well,
primer
primary
objective
was
intolerability
testing
between
the
nts
implementations
or
to
verify
that
the
communication
worked
works
correctly
and,
as
far
as
I
know,
all
of
our
implementations,
based
on
the
latest
craft
version
of
nts
28.,
further
goals,
external
tests
to
check
the
com
plans
with
nts
specification
in
the
implementation,
and
we
also
carried
out
some
performance
tests
next
slide.
Please,
okay,
our
test
setup
included
a
total
number
of
14
ngs
capable
ndp
servers
in
different
countries.
H
They
are
located
in
the
usa,
germany,
netherlands,
singapore
and
sweden,
and
also
we
have
five
different
ndp
implementations
with
nts
support.
Right
now.
I
guess
the
most
popular
are
crony
and
ntp
sag.
We
also
have
cloudflare
an
implementation
from
those
fire
university
ndpo
and
a
hardware
based
solution
on
fpga
next
slide.
H
H
It's
the
same
problem.
We
had
packet
loss
as
we
have
in
the
recent
years
and
therefore
the
nds
key
exchange
works.
The
first
phase,
but
the
secured
ntp
connections
does
not,
and
the
reason
for
this
are
ndp
packets,
which
are
larger
than
secured
packets
and
therefore
filtered
out
on
the
way-
and
I
guess
there's
nothing
we
can
do
about
it.
H
As
the
advanced
ntbs
tests,
miroslav
has
developed
a
tool
for
the
extent
tests
which
covers
the
nds
establishment
protocol
and
it
checks
compliance
with
nts
specification.
Thanks
for
this,
miroslav
is
a
pretty
great
tool
and
yeah.
We
can
download
this
it
on
github
and
it
offers
many
fails,
but
not
serious
problems,
so
the
most
implementations
tolerant,
tolerate
non-critical
errors,
instead
of
avoiding
the
processing
of
the
packet.
So
several
of
these
bugs
are
known
or
intentionally
accepted.
H
So,
for
example,
some
implementations
also
accept
tls
1.2,
but
since
the
last
version
of
nts
only
tls
1.3
is
allowed,
so
you
can
fix
them
pretty
fast,
and
I
think
this
is
not
a
good
idea.
Not
a
big
deal
and
few
bugs
were
fixed
during
the
eckerson
2.
So
I
guess
the
implementations
make
progress
and
the
quality
increases
next
slide.
Please,
okay,.
H
H
H
H
A
little
last
slide
piece
and
yeah.
Thanks
to
our
members
and
organizers,
here's
the
team
member
as
a
list
of
the
team
members
we
are,
we
were
10
members.
As
you
can
see,
kaihino
was
the
first
time
at
the
hackerson,
it's
my
colleague,
and
he
managed
to
test
off
the
firearm
university
on
the
right
side.
You
see
the
links,
so
you
can
download
nts
implementations
and
test
yourself
and
yeah.
I
hope
yeah.
E
About
those
failures
reported
by
the
testing
tool,
it's
not
an
issue
for
the
current
clients,
but
if
the
key
establishment
protocol
is
extended
to
support
an
tbv5
or
maybe
a
completely
different
protocol,
these
issues
could
be
a
real
problem
for
the
client
to
handle.
If
it's
asking
for
something
else,
then
the
mtpv
for
next
protocol
and
it
gets
a
response
with
mtpv4.
E
It
may
not
understand
the
response
correctly
and
this
would
complicate
the
client.
So
I
think
the
issue
is
that
some
of
the
server
implementations-
just
don't
look
at
the
request
and
just
assume
it
will
only
always
be
a
mtpv4
client
and
just
send
a
bunch
of
cookies
and
that's
it
so
yeah
it's.
Maybe
it's
not
a
big
issue
now,
but
it
may
be
in
the
future
in
the
specification
clearly
says
when
the
server
must
respond
with
an
error
or
so
yeah.
A
A
So
the
going
back
I
wanted
to
go
backwards.
Just
a
little
bit
to
the
discussion
we
were
having
on
ntp
v5
and
the
wiki
we're
interested
in
looking
at
the
the
chartering
aspects
of
that,
and
also
it
would
be
helpful
if
we
had
some
documentation
in
place.
So
we've
discussed
rechartering
in
the
past
and
I
didn't
we
don't
have
a
charter
prepared
today.