Re: [ntpwg] Comments on new drafts

[Miroslav Lichvar <[e-mail]>]

On Sat, Apr 09, 2016 at 12:59:39AM +0000, Harlan Stenn wrote:
> > > > > > draft-mayer-ntp-mac-extension-field-00
> > > 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?
> 
> 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.

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) 

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

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

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?

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

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

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

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

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.

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

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.

> If you already sync with a NIST server, does that mean you do not want
> 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.

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

> > You can use a special refid to indicate leap smearing is active and
> > 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.

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

> > 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.
> 
> And several of those conditions you mention will not be valid during the
> leap smear

Which ones?

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

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.

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

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.

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

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.

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

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

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