Subject: [ntpwg] Comments on new drafts

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 7 Apr 2016 14:14:47 +0200

I've few quick comments and questions on the new drafts. I can expand
on that later if there is any interest.

draft-mayer-ntp-mac-extension-field-00
- I'm not sure if hiding the length of the MAC using padding with
  random data is really useful. This was discussed before. The
  attacker can search for the key in parallel using all hash
  functions. As their number is very small, the slowdown is
  insignificant.
- Instead of hiding the hash function, I think it might be more useful
  to specify it directly in the field to allow easier debugging when
  the authentication fails. The MAC length field could be shortened to
  one octet and the other octet could specify the key type, allowing
  256 different types.
- In order to save bandwidth with functions producing long digests,
  they could be truncated to some fixed size, like NTS already does in
  its MAC extension field. Is 128 bits enough?
- MACs could be treated as opaque data, not requiring symmetric keys
  with 32-bit key IDs. This would allow storing MACs from new
  authentication schemes and they wouldn't need a new extension field,
  just a new MAC type for this extension field.

draft-stenn-ntp-i-do-00
- The draft mentions negotiation. Is the server required to keep a
  state of what the client supports? I'd expect it to be a purely
  informational field that doesn't change over time.
- It's not clear to me why there needs to be a "MAC required" bit and
  why it should be specified in this draft. This was discussed before,
  but I've not seen any conclusion.

draft-stenn-ntp-ipv6-refid-hash-00
- The idea was discussed several times before. It doesn't make much
  sense to me. 
- In order to avoid conflicts with refids based on IPv4 addresses it
  makes conflicts between refids based on IPv6 more likely. Why should
  be IPv4 special? The world is quickly moving to IPv6.
- It's an incompatible change making assumptions about how the refid
  is used in clients.

draft-stenn-ntp-leap-smear-refid-00
- I don't think the refid field in NTP packet is a good place to store
  an offset.
- The refid will conflict with 1/256 of refids based on IPv6. Even if
  the IPv6 refid draft that shrinks the space for IPv6 refids to 24
  bits is accepted, it will take some time before it's used.
- This should rather be a new extension field, maybe in a more general
  form that allows different time scales and their offset to UTC to be
  specified.

draft-stenn-ntp-suggest-refid-00
- Again, the "required MAC" bit in the field type doesn't seem useful.
- I'd suggest to use all bits of the refid (not fix the first octet to
  0xfd) to make collisions less likely.
- The extension field could be extended to contain also refids of
  upstream servers (obtained with this extension).
- Instead of hiding the real refid, I'd rather see servers to use this
  extension field to announce the same refid to all clients in order
  to allow them to detect multihomed hosts and duplicates in paths to
  their stratum 1 sources. This is discussed in the other thread.

draft-stenn-ntp-last-extension-00
- Field length of 4 is currently not valid in NTP packets. The minimum
  length is 16 and there are special rules for the last extension
  field. Is there a plan to relax these requirements? (It would be
  an incompatible change.)
- Will be this extension field useful when the new MAC extension field
  is ready? It looks like they have a similar purpose.

-- 
Miroslav Lichvar
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 07 Apr 2016 21:16:26 +0000

>   functions. As their number is very small, the slowdown is

Doing this is a local policy choice.  If you don't want to do it, then
don't.

>   one octet and the other octet could specify the key type, allowing

I see the cost of advertising the hash function.  I don't see the
benefit to advertising the hash function.  If there's a failure, that
should be a very rare event and it should be obvious how to fix it.  It
should also be possible to provide the hash function with a mode 6
query, so authenticated folks can see the hash algorithm.

If the hash function is communicated, I think there are probably better
ways to convey that information besides trying to save 1 byte.

I have no opinion as to whether or not we should limit the size of the
hash to ~256 bytes (if I understood that part correctly).

>   its MAC extension field. Is 128 bits enough?

I'd like to see a clear and complete analysis of the costs and benefits.
Doing this is certainly an option.

>   just a new MAC type for this extension field.

I don't understand "... they wouldn't need a new extension field, just a
new MAC type for this extension field."

The existing and new MAC proposals don't need any changes for new
authentication schemes, from what I can see.

>   informational field that doesn't change over time.

If no state is kept then traditional v4 behavior should be used.

If there is a "peer" structure of some sort, then it's easy to keep a
bit of state.  But again, this is a local policy choice.

And yes, this information may change over time, and either side can
re-issue this exchange.  Two obvious reasons why this might happen
include "Now that we have completed an NTS negotiation, I see that you
qualify for additional authorizations, so I-Do the follwing, if you are
interested", and "Gee, I restarted.  I don't remember what we agreed to
before."

>   but I've not seen any conclusion.

We've had MACs from before we had the first EF.  When autokey arrived,
it *required* a MAC.  Many years' later, we have now just added an
experimental EF that says "there MUST NOT be a MAC."

The bit is "MAC OPTIONAL", not "MAC REQUIRED".  The use of this bit is
backward-compatible with the original behavior.

> - The idea was discussed several times before. It doesn't make much

Then don't implement it, and don't announce that you support it in I-Do
exchanges.

>   be IPv4 special? The world is quickly moving to IPv6.

It uses an initial octet that CANNOT appear as a source address, so
your argument that it "makes conflicts between refids based on IPv6 more
likely" seems ... wrong to me, at least for IPv4-based refids.

For IPv6 refids I think we'd only get a false-positive response in this
case.  And again, this doesn't happen if both sides implement I-Do.

*If* you want to use traditional S2+ refids instead of Sharon's "Not
You" refid, or my suggested-refid, then fine, do that.  If you are OK
with the current setup, then fine, use that.

If you don't want to implement this, then don't.

As I recall, it was 2 trivial lines of code to make this work on each
side, "sending it", and "is that what I got".

Oh, if "The world is quickly moving to IPv6" and the assumption is that
IPv4 will die off soon, then it shouldn't be too long before more folks
upgrade their NTP software. :)

> - It's an incompatible change making assumptions about how the refid

It's easy enough to control when it's used if that's important.

And the cost if one side doesn't implement it is not huge, it's a timing
loop where each side will increase its stratum every poll.  This is a
"self-correcting" problem, in the rare event it happens.

As more software gets upgraded, more systems can be expected to
implement I-Do and then this situation can be better detected.

> - I don't think the refid field in NTP packet is a good place to store

Where else can it go that it's obvious, visible, and almost totally
backward-compatible?

>   bits is accepted, it will take some time before it's used.

Only for client mode associations at the ~S3 level, that do not choose
to implement any of the other proposals around I-Do and refids.

What do you propose as an alternative for servers that want to offer
smeared time to clients?

>   form that allows different time scales and their offset to UTC to be

Feel free to propose that as an alternative.  I specifically chose what
I did because it's very good at being backward-compatible and it's very
visible.

Putting the offset in an EF means clients that don't understand the EF
will either drop the packet completely (a clear lose) or won't know what
to do with it.  Running ntpq -p will not show that the system is
following a leap-smeared system peer.  These limitations are
show-stoppers, in my book.

This issue is *all* about backward-compatibility in the face of people
running out-of-date software.

> - Again, the "required MAC" bit in the field type doesn't seem useful.

Again, what I wrote above.  The bit says "MAC OPTIONAL", and is
backward-compatible.

>   0xfd) to make collisions less likely.

Your suggestion is backwards-incompatible.  We have already seen reports
of the IPv6 hash returing a value that matches the IPv4 address of a
*different IPv4 host on the same network as the IPv6 host*.

Refids are there for 1-degree loop detection, not "who is my upstream
server".

>   upstream servers (obtained with this extension).

Out-of-scope for this proposal, and of unproven value.

>   their stratum 1 sources. This is discussed in the other thread.

It's not hiding the real refid.

The primary reason for the refid is to detect degree-1 timing loops.

There are other ways to do this, and providing information about the
identity of "other servers involved with time exchange" creates security
problems.

>   field. Is there a plan to relax these requirements? (It would be

Then don't use it unless it's agreeable based on I-Do.

If it's agreeable then it's OK to use it.

>   is ready? It looks like they have a similar purpose.

Yes.  If nothing else, it can be useful for broadcast situations where
some clients may not understand MAC-EF but do understand a legacy MAC.

H

---

From: brian utterback <[email-masked]>
Date: Thu, 7 Apr 2016 17:28:57 -0400

> interested", and "Gee, I restarted.  I don't remember what we agreed to

I saw the I-Do also as a possible request function if the extension only
works in one direction. That is something like "I understand X and would
like to get one if you support it".
-- 
Oracle <http://www.oracle.com>
Brian Utterback | Principle Software Engineer
Phone: +1 6038973049 <tel:+1%206038973049>
Oracle Systems/RPE Solaris Network
1 Oracle Dr. | Nashua, NH 03062
------------------------------------------------------------------------
All working systems eventually start to exhibit their own agenda
------------------------------------------------------------------------
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to
developing practices and products that help protect the environment
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Harlan Stenn <[email-masked]>
Date: Thu, 07 Apr 2016 21:46:41 +0000

Hi Brian,

brian utterback writes:
>> include "Now that we have completed an NTS negotiation, I see that
>> you qualify for additional authorizations, so I-Do the follwing, if
>> you are interested", and "Gee, I restarted.  I don't remember what we
>> agreed to before."
> 

The way I intend to implement it and the way I see it being used is:

I Send: I-Do: A, B, D

You Reply: nothing at all
    This probably means either a dropped packet, one direction or the
    other, or "you" dropped the packet because of an unrecognized EF.
    We'd continue using stock NTPv4.

You Reply: normal response
    This is taken to mean "I don't understand what you are offering"
    so we'd use stock NTPv4.

You Reply: I-Do-Response: A, D
    This means that you and I have agreed that A and D are good to use.

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 8 Apr 2016 10:57:26 +0200

On Thu, Apr 07, 2016 at 09:16:26PM +0000, Harlan Stenn wrote:
> should be a very rare event and it should be obvious how to fix it.

Beside knowing which hash function was used in the MAC, the type field
will allow other MACs in the field, not just those used by
authentication with symmetric keys.

> ways to convey that information besides trying to save 1 byte.

If you want to keep the data aligned to 4 octets and not waste too
much space, what else do you propose?

> hash to ~256 bytes (if I understood that part correctly).

The size could be specified in multiplies of 4, if you think 256 is
not enough. I don't.

> new MAC type for this extension field."

The NTS MAC could be stored in this field for instance, it doesn't
have to be a new extension field. If you had multiple MACs in this
field packet, they would be independent. Their order wouldn't change
the result, the second MAC wouldn't have to include the first one, the
third MAC wouldn't need to include the first and second one, and so on.

> experimental EF that says "there MUST NOT be a MAC."

That information is included in the specification of the field. How
will that bit change behaviour of an implementation that doesn't
understand the field? It would be great if you could give an example
of a difference in the processing of the packet when this bit is set
and not set.

> Then don't implement it, and don't announce that you support it in I-Do

If I don't implement it, I won't be able to detect loops with servers
that do implement it. This is not an optional feature as I understand
it. It changes the definition of the refid field in the NTPv4 packets
and everyone has to deal with it.

> likely" seems ... wrong to me, at least for IPv4-based refids.

I mean conflict between two refids generated from two different IPv6
addresses. Your proposal prevents a conflict between IPv6 refids and
IPv4 refids, but at a cost that there will be more conflicts between
IPv6 refids. The 32-bit IPv4 space would be mapped to 32 bits in
refid, but the 128-bit IPv6 space only to 24 bits. Don't you see the
problem?

> Where else can it go that it's obvious, visible, and almost totally

I think the reference timestamp would be a much better choice.

> to implement any of the other proposals around I-Do and refids.

That includes all old implementations, right? I.e. the target of the
proposal?

> What do you propose as an alternative for servers that want to offer

If you need to see the fact that the server is leap smearing in the
ntpq output in the refid field, pick a constant value for refid and
don't encode the offset. That's what I did in chrony.

> Again, what I wrote above.  The bit says "MAC OPTIONAL", and is

Ok, sorry for the confusion.

> *different IPv4 host on the same network as the IPv6 host*.

But the same thing is happening in IPv6-only networks (and you want to
make that problem even more common). The users just need to know the
refid is not an IPv4 address.

> Refids are there for 1-degree loop detection, not "who is my upstream

I disagree. Yes, the main purpose is prevention of loops, but up to
now matching refids of two servers indicated they used the same
source. That is a useful information.

> The primary reason for the refid is to detect degree-1 timing loops.

Ok, so preventing loops between two peers is important, but between
three and more peers it is not?

---

From: Hal Murray <[email-masked]>
Date: Fri, 08 Apr 2016 02:06:35 -0700

[email-masked] said:
> The size could be specified in multiplies of 4, if you think 256 is not
> enough. I don't. 

256 is enough for today.  It won't be tomorrow.

> If you want to keep the data aligned to 4 octets and not waste too much
> space, what else do you propose? 

Table lookup.  There are only a small number of lengths that are likely to be 
used.

-- 
These are my opinions.  I hate spam.

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 08 Apr 2016 10:51:25 +0000

> authentication with symmetric keys.

The security folks tell me that it's better to not advertise the
algorithm.  If you get adequate consensus from them that it's not an
issue to publish the hash function then OK.

Why do you think the described proposal only allows symmetric key
encryption?  It supports autokey as well, and the only other proposed EF
that includes a MAC is NTS, and that protocol embeds its MAC in the NTS
packet, and once the key exchange is completed NTS provides its own MAC.

I asked if the NTS MAC could/should be separated out into a separate MAC
field and was told "No, we want it in the NTS EF."

Oh, what's stopping people from publishing 1 algorithm but actually
using another, again for security purposes?

> much space, what else do you propose?

I already proposed what I think we should do.  Not encode the algorithm
in the MAC.  We've never done it before and there seems to be no
compelling reason to do it now.  There are other ways to get this
information, and they don't seem to be difficult to use.

> The size could be specified in multiplies of 4, if you think 256 is

I don't have the cycles to explore this right now.  We don't need to
think about this if we don't encode the algorithm in the MAC.  And right
now we expressly do not encode the algorithm in the MAC.

> third MAC wouldn't need to include the first and second one, and so on.

The NTS designers have told me they do not want to do this.  The NTS
stuff uses its packet for a bunch of different things.  So you're
suggesting we don't use a new EF for NTS?

> of a difference in the processing of the packet when this bit is set

If I understand you, your first sentence means that the knowledge of
whether or not an EF expects a MAC is known because that knowledge is
embedded in the specification of that EF type.

That fails if the current NTP instance does not know how to process this
"new" EF.

As for examples of how the bits for MAC-OPTIONAL and MAC-INCLUDED, in
what way have I provided incomplete examples or supporting explanation
before?

> and everyone has to deal with it.

It's one thing to use what is described for detection.  It's another
thing to decide to send them yourself.

1) if you implement I-Do then you will be able to say "I don't send this
style of IPv6 refid hash and I don't want you sent it to me, either."
It's up to the "other side" to decide if they're going to honor your
request.

2) You can implement as much or as little of this mechanism to detect
IPv6-based refid hashes as you wish, and decide how many of these
mechanisms to test for along the way.  As I said, this is pretty easy
and lightweight to do.

3) if the Suggest-REFID proposal is implemented, this is a non-issue.

4) if Sharon's idea for "Not-You REFID" is used, this is a non-issue.

5) There are a number of different mechisms proposed around REFIDs.
They are not mutually exclusive.  You should have the flexibility here
to implement a local policy you are comfortable with.

6) if somebody doesn't implement this and they do not detect a loop when
it exists, the stratum of each side will degrade every poll.  And if
they don't have enough other sources of time or they have misconfigured
their systems, and they're not properly monitoring their systems, that's
their problem.

> refid, but the 128-bit IPv6 space only to 24 bits. Don't you see the

Yes. There is a 1 in 16.7M chance of a collision in this case.

The decision to use this mechanism is a local policy choice.

There are collision risks with the original mechanism.

One can use REFID-SUGGEST to avoid this problem, potentially creating a
1 in 16.7M chance of collision with the original IPv6 hash mechanism.

One can use the Not-You refid proposal, which has a 1 in 4B chance of a
collision.

The cost of any of these collisions is that the other side will be
identified as a false-positive timing loop.

That should not be a real problem for anybody.

For REFID-SUGGEST it's possible to periodically change the nonce, which
would limit the period of time when this false-positive condition
exists.

Regardless, if you are a client, you're not serving time so you have no
timing loop issue to worry about.  If you only have 1 source of time,
you have different problems.  If there is benefit to combining the refid
loop detection code with a stratum check that may also be useful.

We have known, active problems with the current refid implementation.

Choose your poison.

> I think the reference timestamp would be a much better choice.

I strongly disagree with you.

1) How does somebody know when the reference timestamp is a reference
timestamp and when it's an offset?  Whether or not the reference
timestamp in its current form is sufficiently useful is a different
discussion.  But we should not "hijack" it without a compelling reason.

2) How is this easily visible from ntpq?

We're talking about making sure things work when things can go sideways
in a major way, about once every 2 years' time, over a period of about
24 hours.  Let's make finding these problems as quick and easy as
possible.

> That includes all old implementations, right? I.e. the target of the

Yes.  And beyond that...

First, I'm not sure I buy the 1/256 collision thing.  How is this not a 1
in 4B chance of collision that would only happen on 1 poll exchange?

If it does happen on 1 poll exchange who cares?  The protocol is robust
enough to handle 1 ignored sample.  Also see above about how a pure
client will never need timing loop detection.

> don't encode the offset. That's what I did in chrony.

What refid value did you choose?

What happens when you have different servers offering different
applications of the leap smear?  How can you tell what they are doing?

> refid is not an IPv4 address.

No, the primary purpose of the refid is for 1-degree loop detection.

If folks want to know about an upstream server and they have
authorization to ask, they can issue a mode 6 request and see what the
source address is for that association.

If your local policy allows for this, great.  But it's unreasonable to
expect others to conform to your policy choices.

The security folks are pushing hard to limit access to this sort of
information.

People who do a lousy job of upgrading their software can expect
problems caused by running outdated software.

> source. That is a useful information.

And dangerous.  So if you want a local policy that allows it, that's
your choice.  Again, it's inapproprate for you to dictate that policy
for others.

Note that more and more folks are making this harder and harder to do.
More to the point, they DO NOT WANT arbitrary folks to know where they
are getting their time from. It's a security thing.

> three and more peers it is not?

Yes.

It may be that larger loops are a problem too, but in those cases it may
be that there are other, earlier problems.

Was it you who mentioned that you saw a 3-system loop, and that loop was
on systems that were using neither orphan mode nor local refclock?  If
that's the case, then please show how increasing the protocol complexity
(including a security analysis) to detect these loops is worth the cost.
Why just not fix the configuration so this doesn't happen?  Why didn't
your systems monitoring catch this when the stratum of your servers went
out-of-spec?

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 8 Apr 2016 15:25:59 +0200

> issue to publish the hash function then OK.

Ok, I can try. Who made the suggestion? Are they following this list?

> using another, again for security purposes?

Sure, they can do that and if it's not a common practice, it might
work. That's security through obscurity. The reasonable approach is to
use secure keys.

> suggesting we don't use a new EF for NTS?

Having all MACs in one extension field looks like a cleaner approach
to me, but I don't want to make that suggestion unless it can be done
without further delaying the NTS draft.

> what way have I provided incomplete examples or supporting explanation

I'd like to see an example where the client or server does anything
differently when the bit is set the other way, i.e. why it needs to be
transferred in NTP packets.

> to implement a local policy you are comfortable with.

If you only want to prevent loop, they might not be exclusive. But if
you want to use refid to detect you are using the same source as your
server, mixing different kinds of refids in the same network will
break it.

> timestamp and when it's an offset?

You can use a special refid to indicate leap smearing is active and
reftime has special meaning.

> Whether or not the reference

Very few client implementations look at the reference timestamp. ntpd
as a client ignores it completely. From how it's specified in NTPv3
and NTPv4, there is about 44 bits that can set arbitrarily without
breaking things. It just needs to be not newer than the transmit
timestamp and not older than few hours.

You could use the encoding specified in the refid draft directly in
the fractional part of the timestamp. You would just need to decrement
seconds by one to make sure it's not newer than the transmit
timestamp. No client would have a problem with that and refid would
stay clean.

> 2) How is this easily visible from ntpq?

ntpq -c rv <assid> prints the reference timestamp.

> in 4B chance of collision that would only happen on 1 poll exchange?

On average 1 in 256 IPv6 servers (using the current definition of
refid) will appear as constantly performing leap smear. If a client
should act on that, it would be a problem. If it's meant only for
humans monitoring the network (who probably can figure out the offset
is not changing and it's a false positive), the draft should make it
clear.

> What refid value did you choose?

127.127.1.255

> applications of the leap smear?

Things might break horribly. 

> How can you tell what they are doing?

There is a command that prints the current leap smearing status and
offset in the chrony monitoring protocol.

> source address is for that association.

Mode 6 is an ntpd-specific extension of NTP. Even if the server runs
ntpd, it's typically disabled. NTP clients can't work with that.

> your systems monitoring catch this when the stratum of your servers went

I think the monitoring caught it, that's not the problem. The problem
was they were unusable for clients below them, it's an unexpected
situation. A local reference was not an option as the servers and
clients were required to always report real synchronisation distance.

---

From: Harlan Stenn <[email-masked]>
Date: Sat, 09 Apr 2016 00:59:39 +0000

> Ok, I can try. Who made the suggestion? Are they following this list?

I believe I heard this from Sharon Goldberg and her team (who are
following this, TTBOMK) and also from at least one of the Cisco teams.

> work. That's security through obscurity. The reasonable approach is to

It's keeping keys secure *and* using acceptable hash algorithms.

The purpose of the MAC is twofold, to detect packet tampering and to
authenticate the packet data.

> without further delaying the NTS draft.

I have no strong opinion on this - I was originally expecting this to be
the approach, in that NTS would do its thing and pass us a MAC that we
would use.  But the NTS designers said "No, we're including the MAC in
our packet and we'll return appropriate status codes to you so you'll
know whether or not the EF contained an authenticator, and whether
or not the packet passed this MAC check."

This goes to the bit in the EF that says "MAC-INCLUDED", as the
timestamps on packets that use NTS cannot be trusted until they are
authenticated or can be reality-checked with other trusted packets.

That's also why I want to *allow* NTS packets to also be covered, at
least initially, with symmetric key MACs.

> transferred in NTP packets.

It goes to allowing the local NTP instance to do some high-level sanity
checks, and to have more information about "should I drop a packet that
contains an EF with no MAC protection or just ignore that EF?"

> server, mixing different kinds of refids in the same network will

Being (usually) able to make that choice is possible with the
traditional REFID.

It was never a defined usage, and how valuable is this capability?

I'm game to tweak the proposed language changes to show that sending the
legacy IPv6 refid hash is deprecated, because we're starting to use
values in the first octet in the 240.0.0.0/4 range for various special
cases.  The calculation is the same, but the proposed new IPv6 refid
puts 0xFF as the first octet.

Returning to your point about other ways refids can be used, do you want
to avoid using a system that is sync'd with a specific refclock driver
just because another of your servers is also using that refclock driver?
What about, for example, all GPS?

If you already sync with a NIST server, does that mean you do not want
to sync with another server that syncs with NIST?

The national labs all sync with each other.  If you are syncing with
NIST do you then want to avoid syncing with PTB?

What exactly is the problem you are trying to solve here?

> reftime has special meaning.

That seems like a lot of work for little gain, and it's a whole lot
messier, IMO.  It's also, as I mentioned, not backward compatible.

> timestamp and not older than few hours.

And several of those conditions you mention will not be valid during the
leap smear, and older software *will not know this* so it seems like
this approach is creating new problems in the very population of clients
where we are trying to solve the leap smear issue.

If folks think this is a useful alternative way to go, however, let's
write it up and get it passed as an alternative mechanism.

> timestamp. No client would have a problem with that and refid would

Yes, and one of the points of this is that we want to CLEARLY identify
that a leap smear is in effect.  So we'd still be offering a "unique"
refid in this case, right?  To keep the proposals someowhat compatible,
we could use 254.a.b.c, where if a.b.c are all 0 the offset is encoded
as you describe in the reference time, and otherwise they are encoded as
I describe.

I still think your approach is suboptimal.  The 'ntpq -p' billboard will
only show a refid of 254.0.0.0 during the entire time of the leap smear,
and one will have to take extra steps to try and get the amount of
smear.

With my proposal, the amount of smear is visible, in an encoded form, in
a single ntpq query.

If one is logging this information, it's arguably easier to log a
timestamp and a refid then it is to log a timestamp, a refid, and a
reference time.  Unless all that information is already being logged.

> ntpq -c rv <assid> prints the reference timestamp.

That's not my idea of easy, and it may not be visible soon as we're
about to implement access restriction control to that sort of data.

> is not changing and it's a false positive), the draft should make it

The proposal is designed to make it easy for monitoring, as the
premise is that the clients are too old/simple to handle a leap second
insertion themselves.

1) they would appear to be constantly applying a *constant* smear.  If
they were *serving time to a client*.  One does not see the refid smear
if one does an 'ntpq -p' query to the server itself.  One does not get a
refid smear if one is using This refid is only
sent in a time response packet to a *client mode* request.

2) Clients do not act on this information.  The whole purpose of sending
leap-smeared time is to send them:

- only in response to client mode requests

- to systems that are expected to be unable to deal with leap seconds

3) if you are in a network where you have upgraded your servers to send
leap-smeared time, how much harder is it to upgrade those servers before
the next leap-second so they include this fix too?  It's already
established that the leap smear is only needed in environments where
there are old clients that do not properly handle leap seconds.  If
these old clients *were* updated there would be no need to use a leap
smear.

4) I had another important point to make about this but I got
interrupted before I could write it down.  It's gone now :)

> > What refid value did you choose?

I implemented what I considered to be the best policy.  You implemented
what you consider to be best policy.

If there is no clear consensus on the "one way to go" let's put both in
the Standard and give folks the option to pick the one they want.

> Mode 6 is an ntpd-specific extension of NTP.

No it's not.  It's part of the NTPv3 Standard that was inadvertently
omitted from the NTPv4 Standard.  Karen mentioned this again last week
at the IETF WG meeting.

> Even if the server runs

That's a local policy choice.  It's trivial in the reference
implementation to control whether or not mode 6/7 queries are answered.

Clients do not need mode 6 for their operation.

Mode 6 is about monitoring and control.

> clients were required to always report real synchronisation distance.

What is the real synchronization difference from a time island?

Does it depend on the reference time and the sync distance at that time,
adding "PHI*elapsed seconds since sync" to that value?

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 12 Apr 2016 11:32:49 +0200

> following this, TTBOMK) and also from at least one of the Cisco teams.

Sharon, can you please comment on this point? What advantages does
hiding the crypto hash have? (beside adding ~2 bits to the space the
attacker has to search) 

> contains an EF with no MAC protection or just ignore that EF?"

Any example in which the client might drop the packet if the bit was
set one way, but not if was set the other way?

> It was never a defined usage, and how valuable is this capability?

Isn't that an obvious usage following from the definition? The
reference ID is defined as a 32-bit code that identifies the source of
the synchronisation. If different clients see different codes, is it
still a reference ID?

> puts 0xFF as the first octet.

Which increases the number of collisions between IPv6-based refids,
creating more false positives in the loop detection and preventing
synchronisation between peers that don't have the same source.

> What about, for example, all GPS?

I might want to do that in some cases. As we have recently seen with
the 13us error in GPS for instance, there are issues that can affect
all refclocks of the same type and it might be useful to group sources
by type.

> to sync with another server that syncs with NIST?

Yes, I might want to ignore the second source. Older ntpd versions
used to do exactly that. If not completely ignore, I might want to at
least decrease the weight of the source. This is up to the
implementation and its configuration.

> messier, IMO.  It's also, as I mentioned, not backward compatible.

I think it is compatible and it is a cleaner approach than encoding
the offset in refid. refid is supposed to identify a source, it's a
discrete variable (unlike reference time).

> leap smear

Which ones?

> and older software *will not know this* so it seems like

I don't think it creates any new problems. The clients either don't
care about reference timestamp at all (this includes ntpd) or they
just check if it's not too old (e.g. older than one day) and not newer
than transmit timestamp. Reference timestamps are normally thousands
of seconds old, a backward adjustment of one second will be well
hidden in this.

> and one will have to take extra steps to try and get the amount of

Yes, an extra command is needed to get the reference time. Considering
how rarely this will be used, I don't see that as a problem. The
offset (encoded in refid or reftime) still needs to be converted to a
decimal value and the user will likely have a script for that.

> omitted from the NTPv4 Standard.  Karen mentioned this again last week

Ok, that's interesting. I hope it won't be added to the NTPv4 spec
until it's fixed/redesigned to not allow traffic amplification.

> adding "PHI*elapsed seconds since sync" to that value?

Yes. With a local reference the server reports zero synchronisation
distance and the clients don't know how far from UTC they are.

---

From: Sharon Goldberg <[email-masked]>
Date: Tue, 12 Apr 2016 18:35:51 -0400

>   functions. As their number is very small, the slowdown is

I agree with Miroslav on this. There is no security benefit in hiding the
hash function being used.  The attacker can just brute force try all hash
functions. There are very few hash function to try.

Other protocols (eg TLS, DNSSEC) advertise their ciphersuites in the clear.

(Note I have not yet read the draft.  Will try to do so soon)

Sharon

---

From: Sharon Goldberg <[email-masked]>
Date: Tue, 12 Apr 2016 18:38:45 -0400

> hiding the crypto hash have? (beside adding ~2 bits to the space the
I agree with Miroslav. There is no benefit to hiding the hash function
(beyond ~2 bits added to the brute force space).  Perhaps something I said
was misunderstood?

I'm strongly in favor of hiding the identity of servers in the refid .
Perhaps that is the source of the confusion.

Sharon