Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ntp-checksum-trailer-04

[Paul Kyzivat <[e-mail]>]

Hi Tal,

On 3/1/16 4:17 AM, Tal Mizrahi wrote:
> Hi Paul,
>
> A new version of the draft has been posted, and I believe it addresses all the comments you raised.
> https://tools.ietf.org/html/draft-ietf-ntp-checksum-trailer-05

Thanks. This rev addresses most of my concerns. I still have one concern:

The revised interoperability discussion in 3.3 doesn't quite capture the 
thing I am worried about. My concern wasn't that an implementation might 
fail to ignore an unknown extension. (I think that has always been 
required.) Rather, my concern is that RFC5905 says when there are 
extensions in the message they will always be followed by a MAC. (There 
is no provision for an extension without a MAC.) So, if you send a 
message with the checksum trailer but without a MAC, and it is received 
by a device that only implements the base 5905, even if the device 
properly ignores unknown extensions, it may still find fault with the 
message and ignore it.

Perhaps plausible implementations won't have such problems. But it would 
be worth mentioning.

	Thanks,
	Paul



> Thanks,
> Tal.
>
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[e-mail]]
>> Sent: Sunday, February 28, 2016 11:38 PM
>> To: Tal Mizrahi; [e-mail]
>> Cc: General Area Review Team; Brian Haberman ([e-mail]);
>> Suresh Krishnan; Karen ODonoghue ([e-mail])
>> Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ntp-checksum-
>> trailer-04
>>
>> Hi Tal,
>>
>> On 2/28/16 1:31 AM, Tal Mizrahi wrote:
>>> Hi Paul,
>>>
>>>
>>>
>>>> Isn't this serious? IIUC in many (most?) cases the transmitters and
>>>> intermediate nodes won't know if the receiver supports [NTP-Ext].
>>>> Inserting this for those that don't will deny them of the time they
>>>> are looking for.
>>>>
>>>> Shouldn't there be some discussion of how a decision can be made
>>>> about when to use this in order to avoid breaking receivers?
>>>
>>>
>>> I believe that the Checksum Complement is most useful in LANs and in
>> locally administered environments, where both client and server are managed
>> by the same administrator. These are the cases where you need a high clock
>> accuracy, and you will want to get the extra juice from hardware
>> timestamping + Checksum Complement.
>>> I believe it is less likely that the Checksum Complement will be used by a
>> client that connects to a random NTP server.
>>>
>>> Having said that, I agree that this should be reflected in the draft, and thus I
>> suggest the following text for Section 3.3:
>>>
>>> "The behavior defined in this document does not impose new requirements
>> on the reception of NTP packets beyond the requirements defined in [NTP-
>> Ext]. Note that, as defined in [NTP-Ext], a host that receives an NTP message
>> with an unknown extension field SHOULD ignore the extension field and MAY
>> drop the packet if policy requires it. Thus, transmitters and intermediate nodes
>> that support the Checksum Complement can transparently interoperate with
>> receivers that are not Checksum-Complement-compliant, as long as these
>> receivers ignore unknown extension fields. It is noted that existing
>> implementations that discard packets with unknown extension fields cannot
>> interoperate with transmitters that use the Checksum Complement.
>>>
>>> It should be noted that when hardware-based timestamping is used, it will
>> likely be used at both ends, and thus both hosts that take part in the protocol
>> will support the functionality described in this memo. If only one of the hosts
>> uses hardware-based timestamping, then the Checksum Complement can only
>> be used if it is known that the peer host can accept the Checksum
>> Complement."
>>
>> OK. That seems like a reasonable way to deal with it.
>>
>>>> I think so. However the erratam also has exactly the text I was
>>>> hoping to find describing how extensions and the mac are parsed out
>>>> of the packet by the receiver, and I don't see that in [NTP-Ext]. In
>>>> principle it is not necessary (it is an exercise for the reader to
>>>> figure out how to do this) but having it ensures that developers get it right.
>>>>
>>>> Is there a reason why [NTP-Ext] doesn't also pick that up from the
>> erratam?
>>>> (Of course that has no bearing on *this* draft.)
>>>
>>> Actually, [NTP-Ext] uses the exact text from the erratum (with some
>> additional text in the middle).
>>
>> What *isn't* in [NTP-Ext] are the notes from the erratum - notably the 2nd
>> one. ISTM that would be very helpful to readers.
>>
>> (But my review of *this* document isn't conditioned on dealing with that.)
>>
>> Do you plan to have a revised version out soon? So far this has been a LC
>> review. I'm also on the hook to to a telechat review. There is an amazingly
>> short gap (two days) between end of LC and the telchat. (I've never seen it so
>> tight. I wonder if people will have time to review a revised document for the
>> telechat?
>>
>> If there is no revised document from the LC before the telechat then I will
>> simply send my same review again as the telechat review, along with a note
>> that we have agreed on some changes. If you plan on getting a new revision
>> out I will try to update my review accordingly.
>>
>> 	Thanks,
>> 	Paul
>
>