Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ntp-checksum-trailer-04
Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 02 March 2016 18:26 UTC
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407951B2CF9 for <gen-art@ietfa.amsl.com>; Wed, 2 Mar 2016 10:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_BzlUd7xY-J for <gen-art@ietfa.amsl.com>; Wed, 2 Mar 2016 10:26:14 -0800 (PST)
Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81BD11B2CF8 for <gen-art@ietf.org>; Wed, 2 Mar 2016 10:26:09 -0800 (PST)
Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-11v.sys.comcast.net with comcast id R6Rs1s0085Geu28016S85b; Wed, 02 Mar 2016 18:26:08 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-po-20v.sys.comcast.net with comcast id R6S61s0023KdFy1016S6Jf; Wed, 02 Mar 2016 18:26:07 +0000
To: Tal Mizrahi <talmi@marvell.com>, "draft-ietf-ntp-checksum-trailer.all@ietf.org" <draft-ietf-ntp-checksum-trailer.all@ietf.org>
References: <56818AED.8090909@alum.mit.edu> <56CCC3D8.7010600@alum.mit.edu> <1fd008bb55c84958aa1b038fe42bf793@IL-EXCH01.marvell.com> <56CF33EE.8040007@alum.mit.edu> <8d092733b39248d69cad3f935f94a896@IL-EXCH01.marvell.com> <56D368B2.20503@alum.mit.edu> <7510e9ba4a2d42c293d746350c7d730c@IL-EXCH01.marvell.com> <56D5E4A0.6060101@alum.mit.edu> <e36ce33e878248a8ae8dc6a934171f40@IL-EXCH01.marvell.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56D7303D.1090107@alum.mit.edu>
Date: Wed, 02 Mar 2016 13:26:05 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <e36ce33e878248a8ae8dc6a934171f40@IL-EXCH01.marvell.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456943168; bh=QfRXDT1vlwEVbOzRaZS7KOAeqOiNlVcyOOZYPA+0WBU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=pbGRKWDZ7QSTM6K18upAqvMZf+F/VjCjqqfvOPAxtzG5uVkF9PqnWcw/8+So3fztz NcRSa8wb9lGdbuZFnB/9f7LvKB3V56V6SMQIw8W2uRYeL1NeP0x1VdgnM5HfaLrqmp wutTe6AeaS/mw65XiJaFlGhuPP4ucugb+qZ1ZmEtZOxPRpI10uE4OxtQ41XIqfZqfS sole8vGm/IV4/QX1CQoYN53nzbKKEuDVbg7mL79jT6dl5wWejGc0B0WtJTi8sGTfZG KiQmvAqhIoXva8jGOjc1bEyR7d1LSeUmvfxppH/gflmW2q0RaI26yzV4HNGhC0foz3 ecwrFjkVZMqnQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/BS_kwoJioc_yLXZsENQt1i2lm7E>
Cc: General Area Review Team <gen-art@ietf.org>, "Brian Haberman (brian@innovationslab.net)" <brian@innovationslab.net>, "Karen ODonoghue (odonoghue@isoc.org)" <odonoghue@isoc.org>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ntp-checksum-trailer-04
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Mar 2016 18:26:16 -0000
On 3/2/16 2:16 AM, Tal Mizrahi wrote: > 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. OK, sorry. I keep forgetting about the erratum. So I'm good with this now. Thanks, Paul > Regards, > Tal. > > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Tuesday, March 01, 2016 8:51 PM >> To: Tal Mizrahi; draft-ietf-ntp-checksum-trailer.all@ietf.org >> Cc: General Area Review Team; Brian Haberman (brian@innovationslab.net); >> Suresh Krishnan; Karen ODonoghue (odonoghue@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:pkyzivat@alum.mit.edu] >>>> Sent: Sunday, February 28, 2016 11:38 PM >>>> To: Tal Mizrahi; draft-ietf-ntp-checksum-trailer.all@ietf.org >>>> Cc: General Area Review Team; Brian Haberman >>>> (brian@innovationslab.net); Suresh Krishnan; Karen ODonoghue >>>> (odonoghue@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] Gen-ART Last Call review of draft-ietf-… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Les Ginsberg (ginsberg)
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- [Gen-art] Gen-ART Telechat review of draft-ietf-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Les Ginsberg (ginsberg)
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Les Ginsberg (ginsberg)
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Xuxiaohu
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Uma Chunduri
- [Gen-art] Gen-ART Telechat review of draft-ietf-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Jari Arkko
- [Gen-art] Gen-ART Last Call review of draft-ietf-… Paul Kyzivat
- [Gen-art] Gen-ART Last Call review of draft-ietf-… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Tal Mizrahi
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Tal Mizrahi
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Tal Mizrahi
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Tal Mizrahi
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Paul Kyzivat
- [Gen-art] Gen-ART Telechat review of draft-ietf-n… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-i… Jari Arkko
- [Gen-art] Gen-ART Last Call review of draft-alaku… Paul Kyzivat
- Re: [Gen-art] Gen-ART Last Call review of draft-a… Zoltan Szabadka
- Re: [Gen-art] Gen-ART Last Call review of draft-a… Paul Kyzivat
- [Gen-art] Gen-ART Telechat review of draft-alakui… Paul Kyzivat
- [Gen-art] Gen-ART Telechat review of draft-alakui… Paul Kyzivat
- Re: [Gen-art] Gen-ART Telechat review of draft-al… Jari Arkko
- [Gen-art] Gen-ART Telechat review of draft-ietf-b… Paul Kyzivat
- Re: [Gen-art] Gen-ART Telechat review of draft-ie… Jari Arkko