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

From: Tal Mizrahi <[email-masked]>
Date: Tue, 1 Mar 2016 09:17:16 +0000

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

>-----Original Message-----
>From: Paul Kyzivat [mailto:[email-masked]]
>Sent: Sunday, February 28, 2016 11:38 PM
>To: Tal Mizrahi; [email-masked]
>Cc: General Area Review Team; Brian Haberman ([email-masked]);
>Suresh Krishnan; Karen ODonoghue ([email-masked])
>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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 1 Mar 2016 13:51:12 -0500

Hi Tal,

> 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

---

From: Tal Mizrahi <[email-masked]>
Date: Wed, 2 Mar 2016 07:16:09 +0000

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.

>Sent: Tuesday, March 01, 2016 8:51 PM
>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.
>>
>>
>>> Cc: General Area Review Team; Brian Haberman
>>> ([email-masked]); Suresh Krishnan; Karen ODonoghue
>>> ([email-masked])
>>> 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.
>>> 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.
>>>>
>>> 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."
>>>
>>>>> 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.
>>>>>
>>> What *isn't* in [NTP-Ext] are the notes from the erratum - notably
>>> the 2nd one. ISTM that would be very helpful to readers.
>>>
>>> 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
>>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 13:26:05 -0500

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

OK, sorry. I keep forgetting about the erratum.

So I'm good with this now.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 2 Mar 2016 13:48:38 -0500

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed by the
IESG for the IETF Chair. Please wait for direction from your document
shepherd or AD before posting a new version of the draft. For more
information, please see the FAQ at <​ 
http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ntp-checksum-trailer-05
Reviewer: Paul Kyzivat
Review Date: 2016-03-02
IETF LC End Date: 2016-03-01
IESG Telechat date: 2016-03-03

Summary:

The -05 version addressed my LC comments on the -04 version.

This draft is ready for publication as a Standards Track RFC.

Major: 0
Minor: 0
Nits: 0

---

From: Jari Arkko <[email-masked]>
Date: Thu, 3 Mar 2016 16:41:58 +0200

Paul, thanks for the review!

And Tal & al, thank you for addressing the comments.

I have balloted no-objection for this document in tonight’s IESG telechat.

Jari