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

[Tal Mizrahi <[e-mail]>]

Hi Paul,


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

Please note that this part of RFC5905 was corrected by erratum 3627 (https://www.rfc-editor.org/errata_search.php?rfc=5905), and the corrected text is:
"In NTPv4, one or more extension fields can be inserted after the header and before the MAC, if a MAC is present. If a MAC is not present, one or more extension fields can be inserted after the header, according to the following rules..."

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

An implementation that complies to the corrected text (from the erratum) will not run into this problem.

Regards,
Tal.



>-----Original Message-----
>From: Paul Kyzivat [mailto:[e-mail]]
>Sent: Tuesday, March 01, 2016 8:51 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 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
>>
>>