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