Re: [ntpwg] Comments on new drafts

[Miroslav Lichvar <[e-mail]>]

On Fri, Apr 08, 2016 at 10:51:25AM +0000, Harlan Stenn wrote:
> Miroslav Lichvar writes:

> > > > draft-mayer-ntp-mac-extension-field-00

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

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

> Oh, what's stopping people from publishing 1 algorithm but actually
> 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.

> 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?

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.

> > > > draft-stenn-ntp-i-do-00

> 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?

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.

> > > > draft-stenn-ntp-ipv6-refid-hash-00

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

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.

> > > > draft-stenn-ntp-leap-smear-refid-00

> > > Where else can it go that it's obvious, visible, and almost totally
> > > backward-compatible?
> > 
> > I think the reference timestamp would be a much better choice.

> 1) How does somebody know when the reference timestamp is a reference
> 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
> timestamp in its current form is sufficiently useful is a different
> discussion.  But we should not "hijack" it without a compelling reason.

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.

> 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?

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.

> > 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.
> 
> What refid value did you choose?

127.127.1.255

> What happens when you have different servers offering different
> 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.

> > > > draft-stenn-ntp-suggest-refid-00

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

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.

> 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?

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.

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