Subject: [ntpwg] [Technical Errata Reported] RFC5905 (3627)

From: RFC Errata System <[email-masked]>
Date: Fri, 17 May 2013 09:28:52 -0700 (PDT)

The following errata report has been submitted for RFC5905,
"Network Time Protocol Version 4: Protocol and Algorithms Specification".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=5905&eid=3627

--------------------------------------
Type: Technical
Reported by: Tal Mizrahi <[email-masked]>

Section: 7.5

Original Text
-------------
In NTPv4, one or more extension fields can be inserted after the header and before the MAC, which is always present when an extension field is present.

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

o If the packet includes a single extension field, the length of the extension field MUST be at least 7 words, i.e., at least 28 octets.

o If the packet includes more than one extension field, the length of the last extension field MUST be at least 28 octets. The length of the other extension fields in this case MUST be at least 16 octets each.

Notes
-----
The usage of NTP extension fields without authentication is aligned with Section 10 of RFC 5906:

The extension field parser initializes a pointer to the first octet beyond the NTP packet header and calculates the number of octets remaining to the end of the packet If the remaining length is 20 (128-bit digest plus 4-octet key ID) or 22 (160-bit digest plus 4-octet key ID), the remaining data are the MAC and parsing is complete.  If the remaining length is greater than 22, an extension field is present.  If the remaining length is less than 8 or not a multiple of 4, a format error has occurred and the packet is discarded; otherwise, the parser increments the pointer by the extension field length and then uses the same rules as above to determine whether a MAC is present or another extension field.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC5905 (draft-ietf-ntp-ntpv4-proto-13)
--------------------------------------
Title               : Network Time Protocol Version 4: Protocol and Algorithms Specification
Publication Date    : June 2010
Author(s)           : D. Mills, J. Martin, Ed., J. Burbank, W. Kasch
Category            : PROPOSED STANDARD
Source              : Network Time Protocol
Area                : Internet
Stream              : IETF
Verifying Party     : IESG
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 21 May 2013 09:02:11 +0200

>>> RFC Errata System <[email-masked]> schrieb am 17.05.2013 um 18:28 in
Nachricht <[email-masked]>:
> In NTPv4, one or more extension fields can be inserted after the header and 
> before the MAC, which is always present when an extension field is present.
> 
> Corrected Text
> --------------
> 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 

Hi!

Wouldn't the phrase "In NTPv4, one or more extension fields can be inserted after the header and 
before the optional MAC. " be more simple?

> extension fields can be inserted after the header, according to the following 
> rules:
> 
> o If the packet includes a single extension field, the length of the 
> extension field MUST be at least 7 words, i.e., at least 28 octets.
> 
> o If the packet includes more than one extension field, the length of the 
> last extension field MUST be at least 28 octets. The length of the other 
> extension fields in this case MUST be at least 16 octets each.
> 
> 
> 
> Notes
> -----
> The extension field parser initializes a pointer to the first octet beyond 
> the NTP packet header and calculates the number of octets remaining to the 
> end of the packet If the remaining length is 20 (128-bit digest plus 4-octet 
> key ID) or 22 (160-bit digest plus 4-octet key ID), the remaining data are the 
> MAC and parsing is complete.  If the remaining length is greater than 22, an 
> extension field is present.  If the remaining length is less than 8 or not a 
> multiple of 4, a format error has occurred and the packet is discarded; 
> otherwise, the parser increments the pointer by the extension field length 
> and then uses the same rules as above to determine whether a MAC is present 
> or another extension field.
> 
> Instructions:
> -------------