draft-stenn-ntp-extension-fields-08.txt   draft-stenn-ntp-extension-fields-09.txt 
Internet Engineering Task Force H. Stenn Internet Engineering Task Force H. Stenn
Internet-Draft D. Mills Internet-Draft D. Mills
Obsoletes: 7822 (if approved) Network Time Foundation Obsoletes: 7822 (if approved) Network Time Foundation
Intended status: Standards Track October 2, 2018 Intended status: Standards Track March 26, 2019
Expires: April 5, 2019 Expires: September 27, 2019
Network Time Protocol Version 4 (NTPv4) Extension Fields Network Time Protocol Version 4 (NTPv4) Extension Fields
draft-stenn-ntp-extension-fields-08 draft-stenn-ntp-extension-fields-09
Abstract Abstract
Network Time Protocol version 4 (NTPv4) defines the optional usage of Network Time Protocol version 4 (NTPv4) defines the optional usage of
extension fields. An extension field, as defined in RFC 5905 extension fields. An extension field, as defined in RFC 5905
[RFC5905] and RFC 5906 [RFC5906], resides after the end of the NTP [RFC5905] and RFC 5906 [RFC5906], resides after the end of the NTP
header and supplies optional capabilities or information that cannot header and supplies optional capabilities or information that cannot
be conveyed in the basic NTP packet. This document updates RFC 5905 be conveyed in the basic NTP packet. This document updates RFC 5905
[RFC5905] by clarifying some points regarding NTP extension fields [RFC5905] by clarifying some points regarding NTP extension fields
and their usage with legacy Message Authentication Codes (MACs), and and their usage with legacy Message Authentication Codes (MACs), and
removes wasteful requirements added by RCF 7822 [RFC7822]. removes wasteful requirements added by RCF 7822 [RFC7822].
This proposal deprecates RFC 7822 [RFC7822]. This proposal deprecates RFC 7822 [RFC7822].
RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH BEFORE PUBLISHING:
The source code and issues list for this draft can be found in
https://github.com/hstenn/ietf-ntp-extension-fields
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 5, 2019. This Internet-Draft will expire on September 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 2.2. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4
3. NTP MAC - RFC 5906 Update . . . . . . . . . . . . . . . . . . 4 3. NTP MAC - RFC 5906 Update . . . . . . . . . . . . . . . . . . 4
3.1. RFC5906 Section 4. - Autokey Cryptography . . . . . . . . 4 3.1. RFC5906 Section 4. - Autokey Cryptography . . . . . . . . 4
3.2. RFC5906 Section 10. - Autokey Protocol Messages . . . . . 4 3.2. RFC5906 Section 10. - Autokey Protocol Messages . . . . . 4
3.3. RFC5906 Section 11.5. - Error Recovery . . . . . . . . . 4 3.3. RFC5906 Section 11.5. - Error Recovery . . . . . . . . . 5
3.4. RFC5906 Section 13. - IANA Consideration . . . . . . . . 4 3.4. RFC5906 Section 13. - IANA Consideration . . . . . . . . 5
4. NTP Extension Fields - RFC 5905 Update . . . . . . . . . . . 5 4. NTP Extension Fields - RFC 5905 Update . . . . . . . . . . . 5
4.1. OLD: 'RFC5905 7.5 - NTP Extension Field Format' . . . . . 5 4.1. OLD: 'RFC5905 7.5 - NTP Extension Field Format' . . . . . 5
4.2. NEW: 'RFC5905 Section 7.5 - NTP Extension Field Format' . 5 4.2. NEW: 'RFC5905 Section 7.5 - NTP Extension Field Format' . 6
4.3. NEW: 'RFC5905 Section 7.5.1 - Extension Fields and MACs' 8 4.3. NEW: 'RFC5905 Section 7.5.1 - Extension Fields and MACs' 8
4.4. OLD: 'RFC5905 Section 9.2. - Peer Process Operations' . . 9 4.4. OLD: 'RFC5905 Section 9.2. - Peer Process Operations' . . 10
4.5. NEW: 'RFC5905 Section 9.2. - Peer Process Operations' . . 9 4.5. NEW: 'RFC5905 Section 9.2. - Peer Process Operations' . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Normative References . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
An NTP packet consists of a set of fixed fields that may be followed An NTP packet consists of a set of fixed fields that may be followed
by optional fields. Two types of optional fields are defined: by optional fields. Two types of optional fields are defined:
extension fields (EFs) as defined in Section 7.5 of RFC 5905 extension fields (EFs) as defined in Section 7.5 of RFC 5905
[RFC5905], and legacy Message Authentication Codes (legacy MACs). [RFC5905], and legacy Message Authentication Codes (legacy MACs).
If a legacy MAC is used, it resides at the end of the packet. This If a legacy MAC is used, it resides at the end of the packet. This
skipping to change at page 7, line 11 skipping to change at page 7, line 25
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
Extension Field Header Format Extension Field Header Format
Where the following Field Type flags are defined: Where the following Field Type flags are defined:
R: 0 for "Information/Query", 1 for a "Response" R: 0 for "Information/Query", 1 for a "Response"
E: 0 for "OK", 1 for an "Error". Unused, and will be deprecated. E: 0 for "OK", 1 for an "Error". Unused, and will be deprecated.
[The 'R' flag is currently used by Autokey, and by the proposed I-DO [The 'R' flag is currently used by Autokey [RFC5906], and by the
extension field. This flag is used after the packet is accepted.] proposed I-DO [DRAFT-I-DO] extension field. This flag is used after
the packet is accepted.]
[The 'E' flag was proposed for use by Autokey, after the packet was [The 'E' flag was proposed for use by Autokey, after the packet was
accepted. As it was never used and no other use-cases have been accepted. As it was never used and no other use-cases have been
identified, we are recommending this flag be deprecated at some point identified, we are recommending this flag be deprecated at some point
in the future.] in the future.]
[The EF Code subtype is currently used by RFC 5906, Autokey [The EF Code subtype is currently used by RFC 5906, Autokey
[RFC5906], by the proposed Extended Information EF proposal, and is [RFC5906], by the proposed Extended Information
expected to be used by the NTS Extension Field, at least.] [DRAFT-EXTENDED-INFORMATION], I-DO [DRAFT-I-DO], and is expected to
be used by the NTS Extension Field, at least.]
The Autokey EF currently uses the most Code values - 10 of them, The Autokey EF currently uses the most Code values - 10 of them,
which equates to the least-significant 4 bits of the high-order which equates to the least-significant 4 bits of the high-order
octet. It is possible that additional flag bits will be allocated; octet. It is possible that additional flag bits will be allocated;
in the past, the high-order 2 bits were reserved, and for a time two in the past, the high-order 2 bits were reserved, and for a time two
additional bits were proposed. Make no assumptions about the unused additional bits were proposed. Make no assumptions about the unused
bits in this octet. bits in this octet.
The EF Header and Body fields (the Flags, Code, Type, and Length, and The EF Header and Body fields (the Flags, Code, Type, and Length, and
any Value or Padding) are specific to the defined functionality and any Value or Padding) are specific to the defined functionality and
skipping to change at page 8, line 33 skipping to change at page 8, line 50
an old system, and two new systems will be able to open a properly- an old system, and two new systems will be able to open a properly-
configured Autokey association. configured Autokey association.
The UDP Checksum Complement extension field forbids the use of a The UDP Checksum Complement extension field forbids the use of a
legacy MAC, so any packet that uses it CANNOT be using a legacy MAC. legacy MAC, so any packet that uses it CANNOT be using a legacy MAC.
[We could list the detailed and specific reasons why traffic using [We could list the detailed and specific reasons why traffic using
this EF is immune to EF/legacy MAC problems, but I fear that would this EF is immune to EF/legacy MAC problems, but I fear that would
just be confusing to most people.] just be confusing to most people.]
The first and best way to prevent ambiguous parsing is to use the The first and best way to prevent ambiguous parsing is to use the
I-DO extension field. I-DO [DRAFT-I-DO] extension field.
By definition any NTP client or server that handles any other By definition any NTP client or server that handles any other
Extension Fields is "new code" and can completely prevent ambiguity Extension Fields is "new code" and can completely prevent ambiguity
by the initiating side sending a packet containing an I-DO extension by the initiating side sending a packet containing an I-DO
field followed by an optional MAC-EF followed by an optional legacy [DRAFT-I-DO] extension field followed by an optional MAC-EF
MAC. The inclusion of any MAC would be dictated by the [DRAFT-MAC-LAST-EF] followed by an optional legacy MAC. The
authentication requirements of the association. inclusion of any MAC would be dictated by the authentication
requirements of the association.
Note that NTP traffic works perfectly well without using any other Note that NTP traffic works perfectly well without using any other
extension fields. Newer extension fields offer additional extension fields. Newer extension fields offer additional
capabilities, but these capabilities are not required for operation. capabilities, but these capabilities are not required for operation.
[Even in the case of NTS or SNT, we're talking about "new code" that [Even in the case of NTS or SNT, we're talking about "new code" that
can be expected to be aware of issues with new extension fields an can be expected to be aware of issues with new extension fields an
legacy MACs.] legacy MACs.]
If the initiating side sends an I-DO packet and gets no response, it If the initiating side sends an I-DO [DRAFT-I-DO] packet and gets no
operates as if the other side cannot handle new extension fields and response, it operates as if the other side cannot handle new
simply continues the association without sending any new extension extension fields and simply continues the association without sending
fields. At any point in the future a packet can be sent with an I-DO any new extension fields. At any point in the future a packet can be
extension field to see if the other side will respond. sent with an I-DO extension field to see if the other side will
respond.
An NTP implementation that receives a packet with an I-DO extension An NTP implementation that receives a packet with an I-DO extension
field may respond with a packet that may or may not contain an I-DO field may respond with a packet that may or may not contain an I-DO
Response. If it does not respond, the other side SHOULD assume that Response. If it does not respond, the other side SHOULD assume that
the receiver does not understand new EFs. If it responds without the receiver does not understand new EFs. If it responds without
sending an I-DO Response extension field, the sending side knows it sending an I-DO Response extension field, the sending side knows it
should not send any new extension fields to this server. If the should not send any new extension fields to this server. If the
system that receives an I-DO extension field responds with an I-DO system that receives an I-DO extension field responds with an I-DO
Response, it's telling the sender exactly what capabilities it is Response, it's telling the sender exactly what capabilities it is
currently willing to exchange. currently willing to exchange.
The second way to prevent ambiguous parsing is to use the LAST-EF The second way to prevent ambiguous parsing is to use the LAST-EF
extension field. [DRAFT-MAC-LAST-EF] extension field.
By definition, if I-DO is used and each side agrees to support LAST- By definition, if I-DO is used and each side agrees to support LAST-
EF then LAST-EF will prevent any ambiguity. EF then LAST-EF will prevent any ambiguity.
If, however, I-DO is not used then one side can simply send a packet If, however, I-DO is not used then one side can simply send a packet
with a LAST-EF. The LAST-EF extension field could be four-octet with a LAST-EF. The LAST-EF extension field could be four-octet
extension field, it could be a 28 octet extension field, or some extension field, it could be a 28 octet extension field, or some
other length that ends on a 32-bit boundary. If the other side other length that ends on a 32-bit boundary. If the other side
responds appropriately then all is well. If the other side does not responds appropriately then all is well. If the other side does not
respond appropriately the sender should proceed without sending any respond appropriately the sender should proceed without sending any
skipping to change at page 11, line 31 skipping to change at page 11, line 31
| 0x0502 | Autokey: Leapseconds Value Message Request | | 0x0502 | Autokey: Leapseconds Value Message Request |
| 0x8502 | Autokey: Leapseconds Value Message Response | | 0x8502 | Autokey: Leapseconds Value Message Response |
| 0x0602 | Autokey: Sign Message Request | | 0x0602 | Autokey: Sign Message Request |
| 0x8602 | Autokey: Sign Message Response | | 0x8602 | Autokey: Sign Message Response |
| 0x0702 | Autokey: IFF Identity Message Request | | 0x0702 | Autokey: IFF Identity Message Request |
| 0x8702 | Autokey: IFF Identity Message Response | | 0x8702 | Autokey: IFF Identity Message Response |
| 0x0802 | Autokey: GQ Identity Message Request | | 0x0802 | Autokey: GQ Identity Message Request |
| 0x8802 | Autokey: GQ Identity Message Response | | 0x8802 | Autokey: GQ Identity Message Response |
| 0x0902 | Autokey: MV Identity Message Request | | 0x0902 | Autokey: MV Identity Message Request |
| 0x8902 | Autokey: MV Identity Message Response | | 0x8902 | Autokey: MV Identity Message Response |
| 0x0003 | * MAC |
| 0x0104 | * NTS Unique Identifier Request |
| 0x8104 | * NTS Unique Identifier Response |
| 0x0204 | * NTS Cookie |
| 0x0304 | * NTS Cookie Placeholder |
| 0x0404 | * NTS AEEF Request |
| 0x8404 | * NTS AEEF Response |
| 0x0005 | Checksum Complement | | 0x0005 | Checksum Complement |
| 0x2005 | Checksum Complement (deprecated flag 0x2000) | | 0x2005 | Checksum Complement (deprecated flag 0x2000) |
| 0x0006 | * Suggest REFID |
| 0x0007 | * I-DO |
| 0x0008 | * LAST-EF |
| 0x0009 | * Extended Information |
| 0x00FF | * thru |
| 0xFDFF | * RESERVED for future I-DO Payloads |
| 0xFEFF | * I-DO Payload: Leap Smear REFIDs |
| 0xFFFF | * I-DO Payload: IPv6 REFID hash |
+------------+----------------------------------------------+ +------------+----------------------------------------------+
* Tentative Reservation
Current Extension Fields Current Extension Fields
7. Security Considerations 7. Security Considerations
Additional information TBD, as needed. The authors know of no adverse consequences of adopting this
proposal.
8. Normative References 8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>. <https://www.rfc-editor.org/info/rfc5905>.
skipping to change at page 12, line 18 skipping to change at page 12, line 37
<https://www.rfc-editor.org/info/rfc5906>. <https://www.rfc-editor.org/info/rfc5906>.
[RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time [RFC7821] Mizrahi, T., "UDP Checksum Complement in the Network Time
Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March Protocol (NTP)", RFC 7821, DOI 10.17487/RFC7821, March
2016, <https://www.rfc-editor.org/info/rfc7821>. 2016, <https://www.rfc-editor.org/info/rfc7821>.
[RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4 [RFC7822] Mizrahi, T. and D. Mayer, "Network Time Protocol Version 4
(NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822, (NTPv4) Extension Fields", RFC 7822, DOI 10.17487/RFC7822,
March 2016, <https://www.rfc-editor.org/info/rfc7822>. March 2016, <https://www.rfc-editor.org/info/rfc7822>.
Authors' Addresses 8.2. Informative References
[DRAFT-EXTENDED-INFORMATION]
Stenn, H., "draft-stenn-ntp-extended-information", 2019.
[DRAFT-I-DO]
Stenn, H., "draft-stenn-ntp-i-do", 2019.
[DRAFT-MAC-LAST-EF]
Stenn, H., "draft-stenn-ntp-mac-last-ef", 2019.
Authors' Addresses
Harlan Stenn Harlan Stenn
Network Time Foundation Network Time Foundation
P.O. Box 918 P.O. Box 918
Talent, OR 97540 Talent, OR 97540
US US
Email: stenn@nwtime.org Email: stenn@nwtime.org
David L. Mills David L. Mills
Network Time Foundation Network Time Foundation
 End of changes. 23 change blocks. 
32 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/