Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-02.txt

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 27 Aug 2015 16:33:39 +0200

On Tue, Jul 21, 2015 at 02:23:41AM -0700, [email-masked] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Network Time Protocol Working Group of the IETF.
> 
>         Title           : UDP Checksum Complement in the Network Time Protocol (NTP)
>         Author          : Tal Mizrahi
> 	Filename        : draft-ietf-ntp-checksum-trailer-02.txt
> 	Pages           : 11
> 	Date            : 2015-07-21

I have some questions on this draft.

It says the new extension field can be used in packets without MAC and
also in packets with MAC, even though it says it's not very useful in
the later case. But it's not clear to me how the checksum complement
can be calculated when a MAC is present. When the value of the
complement is changed to not invalidate the UDP checksum (e.g. after
updating a timestamp), the MAC needs to be updated too as it's
calculated from all data including the timestamp and the complement.
But then the UDP checksum won't match, the complement needs to be
updated again, and we have a cyclic dependency.

Doesn't this require a brute-force attack?

As for interoperability with existing implementations, shouldn't be
a server allowed to use the extension only when the client request had
it? There are NTP implementations that ignore any replies that are not
exactly 48 bytes.

BTW, is anyone working on the "timestamp correction" extension field
that is mentioned in this draft? I'd be very interested in that.

-- 
Miroslav Lichvar
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Tal Mizrahi <[email-masked]>
Date: Sun, 30 Aug 2015 06:21:48 +0000

Hi Miroslav,

Thanks for the comments.
Please see my responses below.

Tal.

>It says the new extension field can be used in packets without MAC and also
>in packets with MAC, even though it says it's not very useful in the later case.
>But it's not clear to me how the checksum complement can be calculated
>when a MAC is present. When the value of the complement is changed to not
>invalidate the UDP checksum (e.g. after updating a timestamp), the MAC
>needs to be updated too as it's calculated from all data including the
>timestamp and the complement.

That is a good point. The checksum complement cannot be updated in the presence of a MAC, and I will update the draft to explain this point.

>As for interoperability with existing implementations, shouldn't be a server
>allowed to use the extension only when the client request had it? There are
>NTP implementations that ignore any replies that are not exactly 48 bytes.

I understand there are implementations that behave this way, but I could not find such a requirement in RFC 5905 - please correct me if I am wrong.
I am not sure we want the *current draft* to be interoperable with unspec'ed behavior. If we believe this is the correct behavior, we should probably start by updating draft-ietf-ntp-extension-field.
I would be interested to hear if other people believe this is the right direction. 

>
>BTW, is anyone working on the "timestamp correction" extension field that is
>mentioned in this draft? I'd be very interested in that.

We (at Marvell) have implemented the hardware aspect of this feature, i.e., timestamping an NTP message + updating its checksum complement.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 31 Aug 2015 15:50:58 +0200

> That is a good point. The checksum complement cannot be updated in the presence of a MAC, and I will update the draft to explain this point.

Ok. Thanks.

> I am not sure we want the *current draft* to be interoperable with unspec'ed behavior. If we believe this is the correct behavior, we should probably start by updating draft-ietf-ntp-extension-fiel…

In draft-ietf-ntp-extension-field-04 there is:

  If a host receives an extension field with an unknown Field Type
  value, the host SHOULD ignore the extension field and MAY drop the
  packet altogether if policy requires it.

which I think describes what the implementations currently do.

I think there may be only two options. Either the implementations are
allowed to drop packets with unknown fields and servers don't use them
unless requested, or clients are required to accept packets with
unknown fields and servers are allowed to use them arbitrarily.

The former has an advantage that it would probably limit the maximum
traffic amplification ratio.

> We (at Marvell) have implemented the hardware aspect of this feature, i.e., timestamping an NTP message + updating its checksum complement. 

If I understand it correctly the checksum complement extension field
makes it easier for you to implement hardware timestamping, which puts
the timestamp closer to the actual time the packet is sent on the
wire.

Now, the question is how to record the delays in the packet processing
on the path between the server and the client, i.e. add support for
NTP "transparent clocks". Something that could be easily implemented
in routers/switches and wouldn't require tracking of all client/server
connections. One possibility I think is an extension field which has
four values: C1, D1, C2, D2.

- C1/C2 is counting how many times the D1/D2 value was updated and
  D1/D2 is the accumulated delay in the processing, all zeroed in the
  client request
- NTP-aware devices on the path to the server increment C1 and add
  their delays between receiving and sending the packet to D1
- NTP server swaps the C1 and D1 values with C2 and D2 in the
  extension field
- NTP-aware devices on the path to the client update C1 and D1
- the client can use the D1 and D2 values to fix the calculated offset
  and delay. If C1 and C2 are not equal, the client knows the two
  paths are different and may discard the sample.

With 1 byte for C1/C2 and 8 bytes for D1/D2 in the NTP timestamp
format that would be 18 bytes of data. That would fit in the padding
in the proposed checksum complement field if you were interested in a
more general form of the "timestamp correction" field.

---

From: Tal Mizrahi <[email-masked]>
Date: Mon, 31 Aug 2015 14:04:46 +0000

Hi Miroslav,

Please see below.

>> We (at Marvell) have implemented the hardware aspect of this feature, i.e.,
>timestamping an NTP message + updating its checksum complement.
>
>If I understand it correctly the checksum complement extension field makes it
>easier for you to implement hardware timestamping, which puts the
>timestamp closer to the actual time the packet is sent on the wire.
>
>Now, the question is how to record the delays in the packet processing on the
>path between the server and the client, i.e. add support for NTP "transparent
>clocks". Something that could be easily implemented in routers/switches and
>wouldn't require tracking of all client/server connections. One possibility I
>think is an extension field which has four values: C1, D1, C2, D2.
>
>With 1 byte for C1/C2 and 8 bytes for D1/D2 in the NTP timestamp format that
>would be 18 bytes of data. That would fit in the padding in the proposed
>checksum complement field if you were interested in a more general form of
>the "timestamp correction" field.
>

The purpose of the current draft is to make life easier for HW-based timestamping. HW-based timestamping on the client+server side can significantly improve the clock accuracy. 
I agree that on-path support (transparent clocks) can improve the accuracy further, but that is not the purpose of the current draft...
BTW, speaking of transparent clocks, wouldn't it be simpler to add an extension field with a <correction field>, as done in PTP?

Thanks,
Tal.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 31 Aug 2015 17:15:45 +0200

> I agree that on-path support (transparent clocks) can improve the accuracy further, but that is not the purpose of the current draft...

Understood. I was just thinking the checksum complement would be
useful for other time stamping corrections too (not just for HW
timestamping on the server or the client) and some of the padding
could be put to use.

> BTW, speaking of transparent clocks, wouldn't it be simpler to add an extension field with a <correction field>, as done in PTP?

That's basically what I'm proposing :). But in NTP we need two fields,
one for the request and one for the reply. The C1 and C2 counters
would I think be a useful addition to that.

---

From: Greg Dowd <[email-masked]>
Date: Mon, 31 Aug 2015 15:43:55 +0000

Probably moving further offtopic but why would you need 2?  And why the counters?  The correction field in PTP was originally designed because the hardware couldn't update the timestamps on the fly.  It would post-process and then send a follow-up with the precise timestamp.   NTP supports that  with the interleave mode.  With today's technology, it's at least possible to simply update the actual timestamp in a MAC/PHY.

However, if we used an extension with a correction field, the receiver would sum the components of the timestamp to calculate the actual receive time.  That could then be stuffed into t2 and no D1 would be in the reply.  

With the counters, it might be interesting to know how many nodes updated the correction field, but I'm not sure what quantitative assessment you could make.  Would you anticipate a dispersion compensation (similar to old stratum calculation) where a fixed error was added per hop?

-----Original Message-----
From: ntpwg [mailto:ntpwg-bounces+greg.dowd=[email-masked]] On Behalf Of Miroslav Lichvar
Sent: Monday, August 31, 2015 8:16 AM
To: Tal Mizrahi
Cc: [email-masked]
Subject: Re: [ntpwg] I-D Action: draft-ietf-ntp-checksum-trailer-02.txt

EXTERNAL EMAIL

> I agree that on-path support (transparent clocks) can improve the accuracy further, but that is not the purpose of the current draft...

Understood. I was just thinking the checksum complement would be useful for other time stamping corrections too (not just for HW timestamping on the server or the client) and some of the padding could be put to use.

> BTW, speaking of transparent clocks, wouldn't it be simpler to add an extension field with a <correction field>, as done in PTP?

That's basically what I'm proposing :). But in NTP we need two fields, one for the request and one for the reply. The C1 and C2 counters would I think be a useful addition to that.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 31 Aug 2015 19:19:50 +0000

Miroslav Lichvar writes:
>>> a server allowed to use the extension only when the client request
>>> had it? There are NTP implementations that ignore any replies that
>>> are not exactly 48 bytes.
>> 
>> I understand there are implementations that behave this way, but I
>> could not find such a requirement in RFC 5905 - please correct me if
>> I am wrong.  I am not sure we want the *current draft* to be
>> interoperable with unspec'ed behavior. If we believe this is the
>> correct behavior, we should probably start by updating
>> draft-ietf-ntp-extension-field.
> 

How does this limit an amplification ratio?

>> We (at Marvell) have implemented the hardware aspect of this feature,
>> i.e., timestamping an NTP message + updating its checksum complement.
> 

I'd be surprised to learn this would make a significant difference.

If you want to have accurate transmit timestamps with a software NTP
implementation, I think folks will need to use interleave mode.

> more general form of the "timestamp correction" field.

I'm curious about the use-case for this.
-- 
Harlan Stenn <[email-masked]>
http://networktimefoundation.org - be a member!
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg