Hi Danny, I had raised a similar point way back in 2008 that we cant assume that the MAC in NTP will always be just 16 bytes.
http://lists.ntp.org/pipermail/ntpwg/2008-December/001435.html Cheers, Manav > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Danny Mayer > Sent: Tuesday, December 13, 2011 7:07 AM > To: David L. Mills > Cc: [email protected]; [email protected] > Subject: Re: [TICTOC] [ntpwg] NTP Extension Field without > Authentication > > Dave, > > You are talking about the current specification. Tal is > talking about changing the specification. > > I see no reason why it cannot be done, provided we can find a > way for it to be specified in a backward compatible way. The > real question is whether or not it should be made optional. > The parsing rules can always be changed, not necessarily > easily, but it can be done. > > RFC 5906 (autokey) should require it whatever is decided. > > Can you remind everyone why we might like to make it not > mandatory? Also we need to have a MAC can we specify the > algorithm/size for the MAC since we shouldn't make > assumptions about this as has been done so far. > > Danny > > On 12/12/2011 1:53 PM, David L. Mills wrote: > > Tai, > > > > All I can say is read my message again. Doing without the MAC is a > > very special case and unintended by the specification. > > > > Dave > > > > Tal Mizrahi wrote: > >> > >> Hi Dave, > >> > >> > >> > >> So you are saying that according to the current spec it is > possible > >> in some configurations to have an extension field without the > >> existence of a MAC? > >> > >> > >> > >> Tal. > >> > >> > >> > >> *From:*David L. Mills [mailto:[email protected]] > >> *Sent:* Monday, December 12, 2011 6:01 AM > >> *To:* Tal Mizrahi > >> *Cc:* [email protected]; [email protected] > >> *Subject:* Re: [ntpwg] [TICTOC] NTP Extension Field without > >> Authentication > >> > >> > >> > >> Tal , > >> > >> It's a little more complicated than it seems. The parsing rules > >> assume that a message digest is always present if an > extension field > >> is present. The NT$ packet header, extension fields and MAC are > >> multiples of 32-bit words. The minimum MAC length is 5 words and > >> maximum length is 6 words. The minimum extension field length is 2 > >> words. If the remaining number of words during the parse > is less than > >> 7, the remainder is the MAC. If not, an extension field is > present. > >> The parser updates the parser pointer folloowing the > extension field > >> and tries again. > >> > >> Thus, if there are at least 7 words remaining and the > extension field > >> eats up all those words, the MAC could be assumed absent . > This is a > >> rather hokey design, but would in principle work. > >> > >> Dave > >> > >> Tal Mizrahi wrote: > >> > >> Hi, > >> > >> > >> > >> Revisiting an issue that was raised a few months ago and > is yet to be > >> resolved: > >> > >> RFC 5905 defines an extension field. The RFC states that a > MAC must > >> be present when there is an extension field. > >> > >> > >> > >> Obviously, it would be beneficial for various purposes to allow > >> Extension Fields independent of whether the MAC is present. > >> > >> > >> > >> Some people thought this is a mistake in the spec, and > that it should > >> be included in the errata. Others thought that Extension Fields > >> without MAC are something new that needs to be defined in > a new document. > >> > >> This was discussed in IETF 81, and then revisited in the ad-hoc > >> meeting in October, but no conclusion was reached. > >> > >> > >> > >> It would be great to hear the opinion of the WG and the > chairs about > >> how to proceed with this. > >> > >> > >> > >> Thanks, > >> > >> Tal. > ------------------------------------------------------------------ > _______________________________________________ > TICTOC mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tictoc > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
