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