Re: [ntpwg] The next step of draft-ietf-ntp-checksum-trailer

[Harlan Stenn <[e-mail]>]

Tal Mizrahi writes:
> Hi All,
> 
> In the last few days we had two main suggestions:
> 
> (1)    Request the value 0x2005 for Checksum Complement extension fields.
> 
> (2)    Remove the requirement to have a fixed length of 28 octets.
> 
> Suggestion (1) will certainly be addressed.
> There was a lot of discussion regarding (2), but it appears that there is n=
> o consensus around the suggestion to remove the 28-octet requirement.
> 
> Two important points should be made:
> 
> -          According to RFC 5905 + erratum 3627 (https://www.rfc-editor.org=
> /errata_search.php?rfc=3D5905), it is not possible for the Checksum Complem=
> ent extension field to be shorter than 28 octets. This restriction is furth=
> er clarified in draft-ietf-ntp-extension-field. Hopefully, future updates t=
> o RFC5905 will place the MAC in its own extension field, and will allow oth=
> er extension fields to be shorter than 28 octets. However, this is currentl=
> y not the case.

I wish I had noticed Errata ID 3627 earlier.  I think it is incorrect on
several counts and I'll be looking to properly document my concerns
about it.

Having said that, I'm OK with the proposal as Tal outlines moving
forward as an experimental document.

Having said that, ...

Autokey was defined with the requirement that its extension field be
protected by a MAC.  The revising language in Errata 3627 does not
address this at all.  One immediate recommendation is that 3627 be
amended to say that a MAC SHOULD be present in any packet that includes
any extension fields.

The language about the algorithms and resulting length of MAC payloads
is not limiting languaage, it is inclusive language.  While 5906
describes an MD5 MAC as producing a 128 bit digest along with a 4 byte
keyid, for a 20 byte MAC, and it also describes a 160 bit digest (with
no alagorithm named) along with a 4 byte keyid, for a 24 byte MAC.  That
in no way means these are the only two digest payload lengths that are
supported.  The NTP Project's Reference Implementation supports other
digest algorithms and resulting lengths as well, even though not all of
these algorithms are presently fully-implemented in the receiving code.
Some of these algorithms produce 512-bit digests, and result in a MAC of
68 bytes' length.

Even by the current logic of 3627, if that disambiguation style is
considered useful, the shortest extension field possible is 4 bytes.  So
any extension field before the current MAC can really be *any* allowed
length, it's only the *last* extension field where there might be an
issue.  In this case, it would be better (and still wrong, I thing) to
say "the last extension field in a packet cannot be 20 or 24 bytes'
long."

Given that we've never specified additional extension fields and nobody
has requested IANA assign additional Field Types, exactly where is the
risk in the disambiguation process I described in my earlier message?

If we're really that concerned about this problem, then all we need to
do is to create a new extension field, 8 bytes long, which indicates "I am
the last extension field", so any data after that would be an old-style
MAC.  Yes, at first thought this would preclude things like the checksum
complement proposal as currently stated, but in actuality it does not,
as as the checksum complement proposal is currently *only* allowed to
work if there is no MAC protection.

> -          The status of draft-ietf-ntp-checksum-trailer is experimental. T=
> hat means that the definition of the Checksum Complement will be revised in=
>  the near future, and this revision may be an opportunity to relax the leng=
> th requirement, assuming that by that time there will be a clear definition=
>  of shorter-than-28-octets extension fields.
> 
> Therefore, I would like to suggest to  leave the 28-octet length requiremen=
> t as-is.

Even so, if 3627 stands it says that the minimum Field Length is 28
octets.  Also requiring it in this proposal means that we have to
eventually clean up the Field Length issue in at least 2 places.
Removing the Field Length requirement in the checksum-complement
proposal means the Field Length should be adequately described somewhere
else, and it is.

But again, this is not a huge deal for me in the context of this
experimental draft.

H
--
> Comments will be welcome.
> Thanks,
> Tal.
_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg