Re: [Ntp] Drafts on interleaved modes and correction field

Hi Miroslav, Aanchal,

Regarding the correction field draft: very interesting draft.

A few comments:

1. Section 3 says that the delay is the time difference between the end of
reception until the beginning of transmission.

  It seems to make more sense to measure the delay as the beginning of
reception until the beginning of transmission, because that is the actual
delay of the packet in practice. BTW, this is also the way IEEE 1588
measures the correctionField.

2. "TBD: Requirements on frequency accuracy of the clock."

   NTP does not define accuracy requirements, and I would suggest to
refrain from defining these here as well.

3. "Delay Correction" - please consider using a format that is identical to
the one defined in IEEE 1588.

4. Section 2 - it would be great if you could clarify the fields "Receive
Correction", "Transmit Correction", and "Origin Correction". Having read
this section a couple of times, I could not figure out the units of these
fields, how they are used, and the rationale of why these fields are
required.

5. "The device MAY update the checksum complement field in order to keep
the UDP checksum valid."
   Since this is a "MAY", please clarify the alternatives: either clear the
UDP Checksum field (in IPv4 only), or recompute the UDP Checksum.

6. Security considerations - I would point out that an attacker that
tampers with the correction extension is (roughly) equivalent to a delay
attacker in terms of the potential damage. Therefore, arguably there is no
point in securing the correction extension. I would recommend to leave the
correction extension out of the integrity protection. This possibility is
mentioned on the second par of Section 7, but I would suggest to rephrase
it to "this is what we recommend".

7. Finally, one may consider a slightly different approach, where each hop
along the path adds a separate extension field, representing the residence
time of the current hop. Obviously this approach has some disadvantages,
but the advantage is that it provides detailed information about the delay
and delay variation in each hop. There is also potential to secure each
extension field separately using its own HMAC. Something to consider...

Regards,
Tal.

On Tue, Oct 31, 2017 at 11:01 AM, Miroslav Lichvar <mlichvar@redhat.com>
wrote:

> Hi,
>
> there are two new drafts intended for the NTP working group.
>
> Aanchal and I have been working on a draft that would specify the
> interleaved modes which are supported in some NTP implementations.
>
> https://tools.ietf.org/html/draft-mlichvar-ntp-interleaved-modes-00
>
> The second draft describes the PTP-like correction field that I
> proposed on this list a couple times, but it never had a more detailed
> specification.
>
> https://tools.ietf.org/html/draft-mlichvar-ntp-correction-field-00
>
> Comments and suggestions are welcome.
>
> --
> Miroslav Lichvar
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>