>>> Steven Sommars <stevesommarsntp@xxxxxxxxx> schrieb am 24.02.2020 um 15:51 in Nachricht <13690_1582555938_5E53E31F_13690_19_1_CAD4huA6nNtJB5=E+dxBvmsLrozkgZ3f-3P=NydCsm =F2Tj_Fw@xxxxxxxxxxxxxx>: > There is substantial size-based blocking of UDP port 123 IPv4 packets by > ISPs/IXPs. From one NTP monitoring point I saw about one third of the NTP > destinations unreachable (dropped en route) for 212-460 byte port 123 > UDP. Another monitoring point experienced blocking for all NTP > destinations when the size was greater than 428 bytes. Size-based NTP > blocking is not a secret; it was discussed on the NANOG mailing list in > 2014 (see for example > https://mailman.nanog.org/pipermail/nanog/2014-February/064634.html ). > NTP requests can be dropped, so section 9.3 of draft 22 does not address > the problem. While NTS will not be a DDoS amplification source, it will > be affected by existing DDoS countermeasures. > > How will NTS work in today's UDP-unfriendly Internet? Maybe a candidate for the best practices: "How to block unwanted NTP packets correctly?", "Should NTP packets be blocked?". Here I can't use any external NTP server, BTW. I feel safe ;-) > > On Fri, Feb 14, 2020 at 8:47 AM The IESG <iesg-secretary@xxxxxxxx> wrote: > >> >> The IESG has received a request from the Network Time Protocol WG (ntp) to >> consider the following document: - 'Network Time Security for the Network >> Time Protocol' >> <draft-ietf-ntp-using-nts-for-ntp-22.txt> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits final >> comments on this action. Please send substantive comments to the >> last-call@xxxxxxxx mailing lists by 2020-02-28. Exceptionally, comments >> may >> be sent to iesg@xxxxxxxx instead. In either case, please retain the >> beginning >> of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This memo specifies Network Time Security (NTS), a mechanism for >> using Transport Layer Security (TLS) and Authenticated Encryption >> with Associated Data (AEAD) to provide cryptographic security for the >> client-server mode of the Network Time Protocol (NTP). >> >> NTS is structured as a suite of two loosely coupled sub-protocols. >> The first (NTS-KE) handles initial authentication and key >> establishment over TLS. The second handles encryption and >> authentication during NTP time synchronization via extension fields >> in the NTP packets, and holds all required state only on the client >> via opaque cookies. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> The document contains these normative downward references. >> See RFC 3967 for additional information: >> rfc5297: Synthetic Initialization Vector (SIV) Authenticated >> Encryption Using the Advanced Encryption Standard (AES) (Informational - >> IETF stream) >> >> >> >> _______________________________________________ >> ntp mailing list >> ntp@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ntp >> -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
