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:pkyzi...@alum.mit.edu] >Sent: Tuesday, March 01, 2016 8:51 PM >To: Tal Mizrahi; draft-ietf-ntp-checksum-trailer....@ietf.org >Cc: General Area Review Team; Brian Haberman (br...@innovationslab.net); >Suresh Krishnan; Karen ODonoghue (odonog...@isoc.org) >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:pkyzi...@alum.mit.edu] >>> Sent: Sunday, February 28, 2016 11:38 PM >>> To: Tal Mizrahi; draft-ietf-ntp-checksum-trailer....@ietf.org >>> Cc: General Area Review Team; Brian Haberman >>> (br...@innovationslab.net); Suresh Krishnan; Karen ODonoghue >>> (odonog...@isoc.org) >>> 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 >> >> _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
