Re: [Ntp] Last Call: <draft-ietf-ntp-using-nts-for-ntp-22.txt> (Network Time Security for the Network Time Protocol) to Proposed Standard

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?

On Fri, Feb 14, 2020 at 8:47 AM The IESG <iesg-secretary@ietf.org> 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@ietf.org mailing lists by 2020-02-28. Exceptionally, comments
> may
> be sent to iesg@ietf.org 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@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>