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

[Miroslav Lichvar <[e-mail]>]

On Tue, Oct 31, 2017 at 01:53:52PM +0200, Tal Mizrahi wrote:
> Regarding the correction field draft: very interesting draft.
> 
> A few comments:

Thanks for the comments, Tal.

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

I think it should to be the same as what the clients and servers use,
otherwise it would create an asymmetric correction when switching
between different link speeds.

As I understand it, PTP assumes that all devices in the network
support PTP (as BC or TC), so it can take the simpler approch using
preamble timestamps for both TX and RX.

With NTP there is generally no HW support, so clients and servers
should use trailer RX timestamps and preamble TX timestamps to avoid
an asymmetric delay with different link speeds. The following document
explains the issue nicely.

https://www.eecis.udel.edu/~mills/stamp.html

Do you think it will be difficult to implement? If the link speed and
length of the packet is known, the timestamp can be transposed.

In any case, I guess this should be explained in the draft.

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

Ok, I was not really sure how it would be specified.

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

Do you think it will be easier to implement that way? Using a
nanosecond field in NTP packets feels dirty to me :).

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

All these fields are in 1/(2^48) of a second. The receive and transmit
corrections are just extensions of the receive and transmit
timestamps. When put together they make fixed point numbers with 32
integer bits and 32 + 16 fractional bits.

The reason for a separate origin field is to allow the client to check
both values before they are applied. If the server adjusted its
timestamp instead, the client wouldn't know by how much and couldn't
limit the impact of a MITM attack.

The reason for a separate transmit correction is to support the
interleaved modes. The receive correction might not be necessary. If
you have a better use for the 2 octets, I think it could be dropped
and included in the origin correction instead.

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

Good point.

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

Ok, I'll do that.

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

I did briefly consider an approach like that, but it seemed to me
there are at least two issues:
- It may allow traffic amplification.
- The growing length of the packet may create an asymmetric delay,
  which I suspect could be completely avoided only in the case where
  all devices on the path support the correction field and preamble
  timestamps are used everywhere.

-- 
Miroslav Lichvar