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

[Tal Mizrahi <[e-mail]>]

Hi Miroslav,

Thanks for the quick response.


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

The link speed is not necessarily known to the end points. Furthermore, the
link speed may change several times along the path.
Maybe I am missing something, but it appears that when measuring
last-bit-in-to-first-bit-out we are ignoring the packet reception time; it
seems to make sense to include the packet reception time in the residence
time.

Moreover, we never know which nodes along the path use store-and-forward,
and which nodes use cut-through. In cut-through forwarding the packet
transmission may start before the last bit is received, so it certainly
makes more sense to measure the first-bit-in-to-first-bit-out.


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

So it looks like two correction fields would suffice: one for the forward
direction, and one for the reverse direction. Right?

Thanks,
Tal.





On Tue, Oct 31, 2017 at 3:52 PM, Miroslav Lichvar <[e-mail]>
wrote:

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