Internet DRAFT - draft-choudharykumar-ntp-ntpv4-extended-extensions
draft-choudharykumar-ntp-ntpv4-extended-extensions
INTERNET-DRAFT V. Choudhary
Intended Status: Standards Track A. Kumar
Updates: 5905 Huawei Technologies India
U. Windl
Universitaet Regensburg
Expires: December 5, 2015 June 3, 2015
The Network Time Protocol Version 4 Extension Format
draft-choudharykumar-ntp-ntpv4-extended-extensions-01
Abstract
The Network Time Protocol Version 4 (NTPv4) defines the optional
usage of extension fields. An extension field as defined in RFC 5905,
is an optional field that resides at the end of the NTP header and
can be used to add optional capabilities or additional information
that is not conveyed in the standard NTP header.
This document redefines NTP extension header proposed in RFC 5905 for
addressing unnecessary padding issue which is required for
differentiating between NTP extension and MAC data.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Vikram & Anil Expires December 5, 2015 [Page 1]
INTERNET DRAFT NTPv4 Extension Format June 3, 2015
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Terms & Abbreviations . . . . . . . . . . . . . . . . . . . 3
2. NTPv4 Extension Format . . . . . . . . . . . . . . . . . . . . 4
2.1 NTPv4 extension header format. . . . . . . . . . . . . . . . 4
2.2. Rules for new extensions. . . . . . . . . . . . . . . . . . 4
2.3. Ensuring backward compatibility. . . . . . . . . . . . . . 5
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 6
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Normative References . . . . . . . . . . . . . . . . . . . 6
5.2 Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
Vikram & Anil Expires December 5, 2015 [Page 2]
INTERNET DRAFT NTPv4 Extension Format June 3, 2015
1 Introduction
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.
This document updates RFC5905 by redefining legacy NTP extension
header format which will help in reducing NTP packet size and ensures
network bandwidth is not wasted just by adding unnecessary padding as
mentioned above. All the new extensions MUST follow the proposed NTP
extension header format.
1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
1.2 Terms & Abbreviations
NTPv4 Network Time Protocol Version 4 [RFC5905]
MAC Message Authentication Code
Vikram & Anil Expires December 5, 2015 [Page 3]
INTERNET DRAFT NTPv4 Extension Format June 3, 2015
2. NTPv4 Extension Format
2.1 NTPv4 extension header format.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Field Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Padding (as needed) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
M-Bit : 1 - More extensions to be followed
0 - No more extensions
o. Removes size restriction for all extension fields
o. Removal of padding saves network bandwidth
o. Backward compatibility is ensured
Note: The proposed solution doesn't help in addressing legacy size
constrains for NTP auto key extensions.
2.2. Rules for new extensions.
New NTPv4 extensions MUST follow below rules :
o. Autokey extension/s MUST be continuous and SHOULD start after NTP
header.
Proposed M-BIT solution cannot be used for Autokey extension as the
MSB (most significant bit) of Autokey Field type is already used for
indicating response messages. If the Autokey extensions are used in
the middle then it won't be possible to indicate whether more/none
extensions are following the current extension or not. Thus Autokey
extensions MUST be the first extension after NTP header and SHOULD
be processed as per the guideline defined by RFC 5906 [RFC5906].
o. First extension following NTP header MUST be at least 28 octets.
This is required for handling legacy MAC issue.
o. First extension following utokey extension MUST be at least 28
octets.
Vikram & Anil Expires December 5, 2015 [Page 4]
INTERNET DRAFT NTPv4 Extension Format June 3, 2015
2.3. Ensuring backward compatibility.
a. NTP packet with no extension/s and MAC.
This is simple as the packet size will be just equal to NTP
header size. No special processing required.
b. NTP packet with MAC only.
NTP packet size as defined in RFC 5905 will be considered for
MAC processing.
c. NTP packet with Autokey extension/s and with/without MAC.
Autokey extension's are the only defined NTP extension's so
current size limitation and processing will remain as defined in
RFC 5905 and 5906.
Vikram & Anil Expires December 5, 2015 [Page 5]
INTERNET DRAFT NTPv4 Extension Format June 3, 2015
3 Security Considerations
The security considerations of the network time protocol are
discussed in [RFC5905]. This document extends current available
extension format for the usage of the NTP extension field, and
thus the described in this document does not introduce new
security considerations.
4 IANA Considerations
There are no new IANA considerations implied by this document.
Field type value for new extensions should consider M-BIT while
requesting IANA.
Example: If a new extension has field type value 0x0009 then it
must request following values to be reserved by IANA.
0x0009 New extension field type (Without M-BIT)
0x8009 New extension field type (With M-BIT)
5 References
5.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14,
RFC 2119, March 1997.
[RFC5905] Mills, D., Martin, J., Burbank, J., Kasch, W.,
"Network Time Protocol Version 4: Protocol and
Algorithms Specification", RFC 5905, June 2010.
5.2 Informative References
[RFC5906] Haberman, B., Mills, D., "Network Time Protocol
Version 4: Autokey Specification", RFC 5906,
June 2010.
Vikram & Anil Expires December 5, 2015 [Page 6]
INTERNET DRAFT NTPv4 Extension Format June 3, 2015
Authors' Addresses
Vikram Choudhary
Huawei Technologies India Pvt. Ltd,
Divyashree Techno Park, Whitefield,
Bangalore, Karnataka 560037,
India
Email: vikram.choudhary@huawei.com
Anil Kumar S N
Huawei Technologies India Pvt. Ltd,
Divyashree Techno Park, Whitefield,
Bangalore, Karnataka 560037,
India
Email: anil.sn@huawei.com
Ulrich Windl
Universitaet Regensburg, Klinikum
EMail: ulrich.windl@rz.uni-regensburg.de
Vikram & Anil Expires December 5, 2015 [Page 7]
