Re: [Ntp] draft-schiff-ntp-chronos-01.txt

[Neta R S <[e-mail]>]

Thanks Greg and Dieter for this discussion,
I will be happy to bring up these ideas in the next IETF meeting (103).

Dieter - regarding Table 1, indeed, small w and the capital W represent the
same quantity
(we will fix it in the next submission).

Thanks,
Neta

On Wed, Oct 31, 2018 at 6:19 PM Dieter Sibold <[e-mail]>
wrote:

> Thanks Greg
> I suppose I’ve got it.
> Dieter
>
> On 30 Oct 2018, at 22:59, [e-mail] wrote:
>
> Somewhat.  My intent was to suggest that the new algorithm should NOT
> replace the current steering part of the loop but instead operate in front
> or alongside or even post (although that would only report, not prevent
> attacks).  I was not focused on the part it would replace (see my other
> comments) but to suggest there is a part it perhaps should not replace.  As
> an example, there is no mention of hysteresis in the secure selection.
> This doesn’t mean it could not include it but it is not necessary to solve
> the security problem.  However, it is vital to the clock steering algorithm
> and supplied in the form of anti-clockhopping and maybe the prefer logic.
> This mix of requirements led to my comments trying to compartmentalize the
> security as an envelope under which the steering could hopefully continue
> to operate without significant noise being introduced.
>
>
>
> Thanks..Greg
>
>
>
>
>
> *Greg Dowd*
>
> Principal Engineer, FTD
>
> Microsemi
>
> 3870 N. First St. | San Jose | CA 95134 | USA
>
> Office: 408.964.7643
>
> Email: *[e-mail] <[e-mail]>*
>
> Company Website:  www.microsemi.com
>
> [image: cid:[e-mail]0E43B0]
>
>
>
>
>
> *From:* Dieter Sibold [mailto:[e-mail]]
> *Sent:* Tuesday, October 30, 2018 1:38 PM
> *To:* Greg Dowd - C32313 <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [Ntp] draft-schiff-ntp-chronos-01.txt
>
>
>
>
>
> Thanks for the answer Greg.
> Does this imply that chronos will „only“ replaces NTP’s selection process?
> After that NTP’s cluster and combination algorithms are applied in order to
> calculate the clock offset. Additionally, chronos will provide an upper
> bound for a valid clock offset?
>
> Dieter
>
>
>
> On 30 Oct 2018, at 17:39, [e-mail] wrote:
>
> Hi Dieter,
>
> This mirrors a statement by Danny recently that information is being lost
> in the suggested approach.  The current clock combining algorithm uses the
> weighted average of the clocks left after the selection algorithm.  This
> provides mitigation against network bias, jitter and clockhopping.  My
> intent in comment 3 was to suggest that instead of using the secure
> selection algorithm to determine a single “jam synchronization”, the secure
> algorithm could perhaps be used as a new “clustering” step that would
> complement or bracket the current produced clock correction.  If the
> filtered, smoothed clock correction is within the bracket, it would be
> used.  If it fell outside, some other step would take place, marking
> outlier as falseticker and re-running or some other step.  This technique
> was discussed I think years ago in the SNTP work and was part of the DSNTP
> (Datum Secure Network Time Protocol) we produced back then.  The idea was
> that the authentication code validated the steering section but did not
> replace it.
>
>
>
> Does that make sense?
>
>
>
>
>
>
>
> *Greg Dowd*
>
> Principal Engineer, FTD
>
> Microsemi
>
> 3870 N. First St. | San Jose | CA 95134 | USA
>
> Office: 408.964.7643
>
> Email: *[e-mail] <[e-mail]>*
>
> Company Website:  www.microsemi.com
>
> [image: cid:[e-mail]0E43B0]
>
>
>
>
>
> *From:* Dieter Sibold [mailto:[e-mail]
> <[e-mail]>]
> *Sent:* Tuesday, October 30, 2018 9:02 AM
> *To:* Greg Dowd - C32313 <[e-mail]>;
> [e-mail]; [e-mail]
> *Subject:* Re: [Ntp] draft-schiff-ntp-chronos-01.txt
>
>
>
> Hi Greg,
>
>
>
> maybe it is only me. But to be honest I don’t understand the third point.
> Especially, what do you mean with the opposite approach? I would like to
> understand your implications.
>
>
>
> Dieter
>
>
>
> *Von: *ntp <[e-mail]> im Auftrag von "[e-mail]"
> <[e-mail]>
> *Datum: *Dienstag, 23. Oktober 2018 um 19:42
> *An: *"[e-mail]" <[e-mail]>, "[e-mail]"
> <[e-mail]>
> *Betreff: *Re: [Ntp] draft-schiff-ntp-chronos-01.txt
>
>
>
> Interesting evolution of the clustering concept.  A couple of thoughts.
>
>    1. It should be possible to perform this operation external to ntpd
>    and then use the resulting information to add/remove servers?  More complex
>    but same functionality?  Certainly cleaner in ntpd.
>    2. It should be possible to modify only the clock selection algorithm
>    and not the clock filtering algorithm although this may be moot if there
>    ends up being a lot of clock hopping.  It would likely result in better
>    precision.
>    3. Instead of taking the average of the sampled servers, have you
>    considered the opposite approach?  That would comprise statistical sampling
>    of the network clocks to validate the current selected clock as a
>    “truechimer”.  This should result in better performance with equivalent
>    security, right?
>
>
>
>
>
> *Greg Dowd*
>
> Principal Engineer, FTD
>
> Microsemi
>
> 3870 N. First St. | San Jose | CA 95134 | USA
>
> Office: 408.964.7643
>
> Email: *[e-mail] <[e-mail]>*
>
> Company Website:  www.microsemi.com
>
> [image: cid:[e-mail]0E43B0]
>
>
>
>
>
> *From:* ntp [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Neta R S
> *Sent:* Tuesday, October 23, 2018 12:56 AM
> *To:* [e-mail]
> *Subject:* [Ntp] draft-schiff-ntp-chronos-01.txt
>
>
>
> EXTERNAL EMAIL
>
> Hi,
>
>
>
> We submitted a new draft for Chronos (see below).
>
> The main change is a hybrid approach: by default NTPv4 updates the local
> clock but when a threat or evidence of attack is detected Chronos time is
> considered.
>
>
>
> Please take a look,
>
> Thanks,
>
> Neta
>
>
>
> Name:           draft-schiff-ntp-chronos
>
> Revision:       01
>
> Title:          A Secure Selection and Filtering Mechanism for the Network
> Time Protocol Version 4
>
> Document date:  2018-10-21
>
> Group:          Individual Submission
>
> Pages:          8
>
> URL:
> https://www.ietf.org/internet-drafts/draft-schiff-ntp-chronos-01.txt
>
> Status:         https://datatracker.ietf.org/doc/draft-schiff-ntp-chronos/
>
> Htmlized:       https://tools.ietf.org/html/draft-schiff-ntp-chronos-01
>
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-schiff-ntp-chronos
>
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-schiff-ntp-chronos-01
>
>
>
> Abstract:
>
>    The Network Time Protocol version 4 (NTPv4) defines the peer process,
>
>    the clock filter algorithm, the system process and the clock
>
>    description algorithm.  The clock filter algorithm and the system
>
>    process, as defined in RFC 5905, are the mechanism according to which
>
>    an NTP client chooses the NTP servers it synchronized with..  This
>
>    document specifies an alternative set of client mechanisms, named
>
>    Chronos, that is backward compatible with NTPv4, and offers an
>
>    improved level of security against time shifting attacks.
>
>
>
>