Hi Tim,
I am sorry I missed your other comments (except the one regarding Byzantine attackers) before.
Please see me reply inline (in purple).
Best,
Neta
On Thu, Jul 6, 2023 at 3:20 AM Tim Chown <Tim.Chown@xxxxxxxxxx> wrote:
Hi,
In-line...
On 5 Jul 2023, at 02:20, Neta R S <neta.r.schiff@xxxxxxxxx> wrote:
Thanks for your feedback.Please see my responses inline below (in blue).
Best,Neta
On Mon, Jul 3, 2023 at 12:21 PM Tim Chown via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Tim Chown
Review result: Ready with Nits
Hi,
I have reviewed this document as part of the Internet Area directorate's
ongoing effort to review all IETF documents being processed by the IESG. These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review. Document editors and WG chairs should
treat these comments just like any other last call comments.
This document describes a tool named Khronos which can be run alongside NTPv4
to mitigate against time-shifting attacks. It achieves this by running less
frequent (than NTP) queries to a small random set of NTP servers (around
~10-15) drawn from a large pool (perhaps ~500), and comparing the resulting
time offsets to those of the system NTP clock.
The document is generally well-written, and for its heavier theoretical detail
refers to a paper published elsewhere by the authors.
I believe the document is close to being ready for publication (Ready with
Nits). I have only a small number of general comments and nits.
General comments:
The term man in the middle (MitM) is used a lot, and includes scenarios where
an attacker owns the NTP server being queried. Personally, I’d not consider
that a MitM attack as I’d consider the “middle” the elements between the client
and server. Maybe clarify your meaning.
>> We consider both a MitM attacker with capabilities to alter and inject NTP traffic on behalf of a given NTP server and an attacker that controls a server. Both attacks have a similar impact on the victim client and therefore we address them both in similar manner. I simplified a bit the threat model referenced.Right, but the text describes a compromised server as a MitM attack, which personally I don’t think is true.
I fixed these descriptions across the draft.
Is there an assessment of the impact on the existing NTP pool if Khronos is
widely implemented? It seems that there will be more queries overall, but
perhaps to a more scattered set of servers?
>> Yes, this is a good observation, Khronos queries will be uniformly scattered over the NTP pool. Moreover, while Khronos queries around 3 times more servers per polling interval compared to NTPv4 (around 12 instead of 4), we suggest, in the draft, to use a 10 times longer polling interval. Therefore, I don’t expect a significant increment to the average NTP servers’ load.So it may be useful to include a short section on operational impact on existing NTP infrastructure. I’d expect the ops-dir review to mention this too.
Thanks, I added this note to the existing discussion on minimizing the load on NTP servers. Since previous reviewers requested this to be discussed already in the Introduction due to its importance, I improved that discussion following your comments.
On the security side, does it matter than an observer may be able to detect
when Khronos is being used, by its use of ~500 NTP servers instead of the usual
small fixed number of servers?
>> Khronos uses a pool of hundreds of servers, but queries only approximately 12 servers in each Khronos polling interval. In any case identifying its operation doesn’t impact its security (since each time different servers are chosen at random).So state that in the security considerations?
Thanks, I added it (to the security considerations).
Also, how ‘random’ is the selection of servers from the pool? Might it be
predictable, and if so does that pose risks?
>> It is not explicitly mentioned, but the implementation should make sure to use a safe random implementation (same one used for encryption key generation for example /dev/random in unix).So again that should be stated.
Thanks, I added this important note to the design section.
I suppose certain MitM vulnerabilities are more ‘sweeping’ than others, like a
bad actor controlling a major or exclusively used uplink, and thus rather
harder to even impossible to mitigate? This is the worst case of the second
scenario in 4.3? (Which also seems to say >2/3 controlled, then just below 1/4
controlled?).
>> Section 4.3 analyzes the possible outcome of a single polling interval, among the (m) samples obtained in this interval. It may happen that 2/3 of them arrived from compromised servers even if only ¼ of the entire NTP pool is compromised (although with low probability).
OK.
Nits:
The word ‘byzantine’ is used several times before it is explained, even with
forward references (except in the start of 4.1) to 4.3, and then in 4.3 I can't
find any use of the word. It would be nice to have it explained on first use.
>> Byzantine is just a term commonly used in distributed computing to represent a powerful generic attacker, for example the attacker is aware of the protocols run by others but is not limited to acting by them. I simplified the relevant sentence in the Introduction to show that Byzantine has no special meaning in this contest. I leave it there for the relation to the distributed computing literature.I’ve never heard of the term, and have a fair amount of experience in cyber, less so in classic distributed computing.
In the -18 version you’ve improved it but I’d suggest changing “(Byzantine)” in section 1 to “(which distributed computing literature often refer to as Byzantine attackers)” or something very similar. I think for an IETF doc you could just omit it.
Tim
In a few places the section referencing appears as Section Section.
>> Thanks, I fixed it.
A couple of Khoronos instances (extra ‘o’).
>> Thanks, I fixed it.
Best wishes,
Tim
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
