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

[Miroslav Lichvar <[e-mail]>]

On Sun, Aug 30, 2015 at 06:21:48AM +0000, Tal Mizrahi wrote:
> >But then the UDP checksum won't match, the complement needs to be
> >updated again, and we have a cyclic dependency.
> >
> 
> 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.

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

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.

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

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.

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