Re: [Ntp] WGLC: draft-ietf-ntp-chronos

[Hal Murray <[e-mail]>]

Apologies for not getting my act together sooner.

I don't like it.

I expect to read a page or 2 (after skipping boilerplate) and then be able to 
decide if this idea is worth implementing.

What are the costs?  What are the benefits?

I think the threat model needs to be discussed early on.  MitM isn't mentined 
until Section 6.  What parts of that is Chronos protecting against?

Probably tangled up with that is the way the target client is being run.  How 
many servers?  Are they carefully selected or does it use the pool? ...

How do I evaluate the goodness of a particular Chornos setup?  I'd like a 
simple formula.  I'm looking for the big picture?  Is it exponential or sqrt?  
If there is no reasonable formula, maybe a small table would be good enough.

The costs are extra traffic to the servers.  If my server is currently using 5 
servers and I add Chronos using m=15 from your example, thats adding 3x load 
on the servers.  (total of 4x).  That's a pretty steep price.

-------

Chronos is described as an add-on, off to the side.  Can we merge it in with 
the main ntpd flow?

Handwave:
  step 1: add m more servers
  step 2: replace those servers every polling interval
  step 3: check for attacks

Checking for attacks may be useful even without the rest of Chornos. 

-------

Editorial level comments.

Plase drop all the references to NTPv5.  I find them all distracting.  If you 
really think that is important, put a paragraph at the end, and list all the 
properties of NTPv4 that need to be preserved for Chronos to keep working on 
NTPv5.

Page 3: "chooses a small subset of the NTP server pool"
  You made an interesting assumption there.
  Is Chronos useful if I select servers by hand?  What if they are all nearby 
and much higher quality servers than the ones in the pool?

Note that the word pool is ambigious.  It could mean pool.ntp.org, or it could 
mean the collection of servers, size n, that Chronos is using.  I suggest "NTP 
pool" and "Chronos pool", or its pool.

Page 3:  "preserving high accuracy and precision"
  I think you need to explain what you mean by "high".  Without qualification, 
my reading would be as good as when not under attack and that doesn't seem 
reasonable.

Page 3:  "provably secure algorithm".
  What are the conditions or assumptions that proof needs?

Page 3:  "avoid overloading NTP servers"
  I think you mean minimize the load on NTP servers.  Overload depends on the 
ratio of servers to clients as well as the load from a typical client.

I'm not sure where "communication overhead" comes from.  What's "overhead" 
about a NTP request/response exchange?

Page 3: "100 milliseconds", "20 years".
  That doesn't sound right.  All the MitM has to do is delay all replies by 
200 ms.  That "all replies" covers both ntpd and Chrnos.  There is no way to 
tell that case from an additiional 100 ms of cable.
  You are throwing numbers around without stating the conditions.

Page 3-4:  "in order to avoid overloading the servers"
  The way I read that, you have already picked m, so using m out of n won't 
reduce the load on the pool.  Maybe you mean using m rather than all n will 
reduce the load.  I suggest dropping the "overload" part.

Page 5: "Chronos poll interval"
  Is that different from ntpd's poll interval?

Page 5: m servers and m Chronos servers.
  Why should Chronos use the same number of servers as main ntpd?

Page 5: Sectopm 3.1
  It goes through the clock filter algorithm, then selects the "union of all 
recieved NTP servers' IP Addresses".  If you are going to select all the 
servers, why go through the filter?  I assume you want to select only the good 
ones, but that's not what the text says.

Page 7: "probability of reaching panic mode"
  I can't figure out what that paragraph is saying.  I think you are talking 
about false positives - reaching panic mode when you shouldn't, but the "when 
you shouldn't" isn't in your text.  Again, a table would be nice.  0.000002 is 
not negligible in some applications.

-------

Bufferbloat might be an interesting form of attack to consider.  It will get 
all of the Chronos servers no matter how big the pool is.  (My old DSL line 
had enough bloat that ntpd would step the clock if I did a long enough 
download.)

Another form of attack would be bugs.  There was one in gpsd recently.  That 
probably hit an interesting fraction of the pool.  I doubt if it was as big as 
25%.

How well does Chronos work with NTS?   NTS requires storage of keys and 
cookies for each server in the Chronos pool.

NTS cookies have a lifetime of 24 hours.  If I use your m=15 and n=500, each 
server gets used on average every 33 polls.  If the polling interval is 1024 
seconds, each server gets used (on average) every 9 hours.  That will require 
some careful coding but I think it will be OK.  It also turns into an upper 
bound on the ratio of n to m.  m=15 with n=5000 won't work.

--------

Typos:
  Section 3.2: "that,on average" missing space

  Section 4, Pseudocode
     "return avg(t)"  t isn't used yet.  I assume you mean T.





-- 
These are my opinions.  I hate spam.