%% You should probably cite draft-ietf-ntp-refid-updates instead of this I-D.
@techreport{stenn-ntp-not-you-refid-00,
    number =    {draft-stenn-ntp-not-you-refid-00},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-stenn-ntp-not-you-refid/00/},
    author =    {Sharon Goldberg and Harlan Stenn},
    title =     {{Network Time Protocol Not You REFID}},
    pagetotal = 5,
    year =      2016,
    month =     jul,
    day =       8,
    abstract =  {NTP has been widely used through several revisions, with the latest being RFC 5905 {[}RFC5905{]}. A core component of the protocol and the algoritms is the Reference ID, or REFID, which is used to identify the source of time used for synchronization (aka the "system peer"). Traditionally, when the source of time was another system, the REFID was the IPv4 address of that other system. The 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, then A should not then decide to get its time from B. The REFID is therefore a vital core-component of the base NTP packet. If a system's REFID is the IPv4 address of its time source, then with a simple query a remote attacker can learn the target's REFID. The remote attacker can then try to use that information to send spoofed NTP packets to the target or the target's time source, attempting to cause a disruption in time service {[}NDSS16{]}. Since the core purpose of the REFID is to prevent a one-degree timing loop, this proposal is a backward-compatible way to limit the amount of information that is leaked in the REFID. Specifically, it allows the prevention of one- degree timing loops by allowing a system A to reveal to a querying system B that B is not A's time source, but without revealing the actual time source to which A is synchronized.},
}