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

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 31 Oct 2017 10:01:39 +0100

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

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 31 Oct 2017 13:53:52 +0200

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 <[email-masked]>
wrote:

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 31 Oct 2017 14:52:47 +0100

> Regarding the correction field draft: very interesting draft.

Thanks for the comments, Tal.

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

> refrain from defining these here as well.

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

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

> fields, how they are used, and the rationale of why these fields are

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.

> UDP Checksum field (in IPv4 only), or recompute the UDP Checksum.

Good point.

> it to "this is what we recommend".

Ok, I'll do that.

> 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

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 31 Oct 2017 16:59:52 +0200

Hi Miroslav,

Thanks for the quick response.

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

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

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 31 Oct 2017 16:57:17 +0100

On Tue, Oct 31, 2017 at 04:59:52PM +0200, Tal Mizrahi wrote:
> The link speed is not necessarily known to the end points.

I meant that the devices which are supposed to modify the correction
field know the link speed and can transpose preamble timestamps if
necessary.

The end points don't need to know the link speed on the path. Just the
speed of their own link if they need to transpose their timestamps.

> Furthermore, the

In such case we want the correction to still be symmetric, right?

> seems to make sense to include the packet reception time in the residence

For PTP yes, but not for NTP. The reception time is included in the
network delay as measured by the client, which will be symmetric as
long as no device on the path includes in the correction the
transmission time or reception time.

> makes more sense to measure the first-bit-in-to-first-bit-out.

That's a good point. With cut-through switching the correction would
be negative and generally couldn't be determined in time to be put in
the packet as the length is unknown. Are there any switches that can
cut-through from a faster link to slower link?

Maybe it would make sense to allow corrections from preamble RX
timestamps when the link speeds are equal.

> direction, and one for the reverse direction. Right?

I think it's three fields if we want both support the interleaved
modes and allow the client to check the delay correction in both
directions. Where would be the transmit correction included if there
were only two fields?

-- 
Miroslav Lichvar

---

From: Greg Dowd <[email-masked]>
Date: Tue, 31 Oct 2017 15:58:41 +0000

In general, network protocols other than PTP (e.g., NTP, Y.1544) use beginning of transmit and end of receipt.  PTP was somewhat unique in its awareness of hardware timestamping at the application layer.  Can we just fixup the timestamp as the hardware will know the link speed?

…Greg

From: ntp [mailto:[email-masked]] On Behalf Of Tal Mizrahi
Sent: Tuesday, October 31, 2017 8:00 AM
To: Miroslav Lichvar <[email-masked]>
Cc: Aanchal Malhotra <[email-masked]>; [email-masked]
Subject: Re: [Ntp] Drafts on interleaved modes and correction field

EXTERNAL EMAIL
Hi Miroslav,

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

>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 <[email-masked]<mailto:[email-masked]>> wrote:

Good point.

Ok, I'll do that.

--
Miroslav Lichvar

---

From: Greg Dowd <[email-masked]>
Date: Tue, 31 Oct 2017 16:02:32 +0000

I think switches have to use store and forward on link speed changes.  In theory maybe fast to slow doesn't have to but slow to fast of course does.  Tal may know more.  

-----Original Message-----
From: ntp [mailto:[email-masked]] On Behalf Of Miroslav Lichvar
Sent: Tuesday, October 31, 2017 8:57 AM
To: Tal Mizrahi <[email-masked]>
Cc: Aanchal Malhotra <[email-masked]>; [email-masked]
Subject: Re: [Ntp] Drafts on interleaved modes and correction field

EXTERNAL EMAIL

On Tue, Oct 31, 2017 at 04:59:52PM +0200, Tal Mizrahi wrote:
> >an asymmetric delay with different link speeds. The following 
> >document explains the issue nicely.
> >

I meant that the devices which are supposed to modify the correction field know the link speed and can transpose preamble timestamps if necessary.

The end points don't need to know the link speed on the path. Just the speed of their own link if they need to transpose their timestamps.

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

For PTP yes, but not for NTP. The reception time is included in the network delay as measured by the client, which will be symmetric as long as no device on the path includes in the correction the transmission time or reception 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.

That's a good point. With cut-through switching the correction would be negative and generally couldn't be determined in time to be put in the packet as the length is unknown. Are there any switches that can cut-through from a faster link to slower link?

Maybe it would make sense to allow corrections from preamble RX timestamps when the link speeds are equal.

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

I think it's three fields if we want both support the interleaved modes and allow the client to check the delay correction in both directions. Where would be the transmit correction included if there were only two fields?

--
Miroslav Lichvar

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 1 Nov 2017 08:48:48 +0200

Hi Miroslav,

>cut-through from a faster link to slower link?

To the best of my knowledge cut-through from a fast link to a slow link is
not possible. Cut-through from a slow link to a fast link is certainly
possible, and of course between ports that have the same link speed.
In the two latter cases the transmission may start before the end of the
reception.

Regards,
Tal.