[Ntp] Antw: I-D Action: draft-stenn-ntp-suggest-refid-04.txt

["Ulrich Windl" <[e-mail]>]

I think the abstract is too long and contains unnecessary details.
What about a shorter version like this?:
   NTP has been widely used through several revisions, with the latest
   being RFC 5905 [RFC5905].  A core component of the protocol and the
   algorithms is the Reference ID, or REFID, which is used to identify
   the source of time used for synchronization.  Traditionally, when the
   source of time was another system the REFID was the IPv4 address of
   that other system.  The core purpose of the REFID is to prevent a
   one-degree timing loop.  The REFID being part of the base NTP packet
   is considered to be "public data".
   The traditional REFID being derived directly from an IPv4 address needs
   to apply for IPv6 addresses as well.  This proposal is a backward-
   compatible way for a time source to produce a REFID from which the IP
   address of the time source should not be derivable.

I wonder whether a capitalized SHOULD should be used in the abstract, BTW.

Regards,
Ulrich
P.S: Haven't read the complete text yet.

>>> <[e-mail]> schrieb am 03.10.2018 um 09:14 in Nachricht
<[e-mail]>:

> A New Internet‑Draft is available from the on‑line Internet‑Drafts
directories.
> This draft is a work item of the Network Time Protocol WG of the IETF.
> 
>         Title           : Network Time Protocol Suggest REFID Extension 
> Field
>         Author          : Harlan Stenn
> 	Filename        : draft‑stenn‑ntp‑suggest‑refid‑04.txt
> 	Pages           : 6
> 	Date            : 2018‑10‑03
> 
> Abstract:
>    NTP has been widely used through several revisions, with the latest
>    being RFC 5905 [RFC5905].  A core component of the protocol and the
>    algorithms is the Reference ID, or REFID, which is used to identify
>    the source of time used for synchronization.  Traditionally, when the
>    source of time was another system the REFID was the IPv4 address of
>    that other system.  The core purpose of the REFID is to prevent a
>    one‑degree timing loop, where if A has several timing sources that
>    include B, if B decides to get its time from A we don't want A then
>    deciding to get its time from B.  The REFID is considered to be
>    "public data" and is a vital core‑component of the base NTP packet.
>    If a system's REFID is the IPv4 address of its system peer, an
>    attacker can try to use that information to send spoofed time packets
>    to either or both the target or the target's server, attempting to
>    cause a disruption in time service.  This proposal is a backward‑
>    compatible way for a time source to tell its peers or clients "If you
>    use me as your system peer, use this nonce as your REFID."  This
>    nonce SHOULD be untraceable to the original system, and if it is used
>    as the REFID this type of attack is prevented.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft‑stenn‑ntp‑suggest‑refid/ 
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft‑stenn‑ntp‑suggest‑refid‑04 
> https://datatracker.ietf.org/doc/html/draft‑stenn‑ntp‑suggest‑refid‑04 
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft‑stenn‑ntp‑suggest‑refid‑04 
> 
> 
> Please note that it may take a couple of minutes from the time of
submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet‑Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet‑drafts/ 
> 
> _______________________________________________
> ntp mailing list
> [e-mail] 
> https://www.ietf.org/mailman/listinfo/ntp