Network Time Protocol MAC/Last Extension Fields
draft-stenn-ntp-mac-last-ef-00
| Document | Type | Expired Internet-Draft (individual) | |
|---|---|---|---|
| Last updated | 2017-05-02 (latest revision 2016-10-29) | ||
| Stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats |
Expired & archived
plain text
pdf
html
bibtex
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus Boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
https://www.ietf.org/archive/id/draft-stenn-ntp-mac-last-ef-00.txt
Abstract
NTPv4 is defined by RFC 5905 [RFC5905], and it and earlier versions of the NTP Protocol have supported symmetric private key Message Authentication Code (MAC) authentication. MACs were first described in Appendix C of RFC 1305 [RFC1305] and are further described in RFC 5905 [RFC5905]. As the number of Extension Fields grows there is an increasing chance of a parsing ambiguity when deciding if the "next" set of data is an Extension Field or a legacy MAC. This proposal defines two new Extension Fields to avoid this ambiguity. One is used to signifiy that it is the last Extension Field in the packet. If present, any subsequent data MUST be considered to be a legacy MAC. The other allows one or more MACs to be encapsulated in an Extension Field. If all parties in an association support MAC-EF, the use of a legacy MAC may be avoided.
Authors
Harlan Stenn
(stenn@nwtime.org)
Danny Mayer
(mayer@ntp.org)
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)