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

Steven Sommars <> Mon, 24 February 2020 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 84B7E3A0CA2; Mon, 24 Feb 2020 06:52:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iQl54oo2Qr5M; Mon, 24 Feb 2020 06:52:02 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 53D433A0CA0; Mon, 24 Feb 2020 06:51:59 -0800 (PST)
Received: by with SMTP id n27so5849429vsa.0; Mon, 24 Feb 2020 06:51:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=65ICzsNaGkvvdFXWrfkSJQ9TY75YIgAtezXdwgRC8uE=; b=j1b/qpPQAuKzhlER7rR3XNyMvqCIOme16bv5LN8aUpX87+Nz54jcFjEI2oHhToJde+ tnd+Vz6gV8UbsBNfoPwxl/n+lF7hgstpKVf7DnyUpUyyHAloKuK303An12zBLWvb5FjB pQDlutp6YfmLIx2nby4RU3+PkFhxRJhsFQc2WKtEg8bGGLfIum8wBEMX1fZ3VKfa/CNU E70ipQi1RLfExORhMZk10TZ+zUij9NuBkds52mNf3yeQc4Yvu/Bby1/ESDoHBXfEDiQE OM1jKjerKntdddardHewQ4VNXwxCQVdBXKMUnHv15Ul5KaxYS8QXw+Fg9yPOQVjsg78b ExMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=65ICzsNaGkvvdFXWrfkSJQ9TY75YIgAtezXdwgRC8uE=; b=RPjMXfsXC0cD4bO8GMT3OUgX4f63kYPuGUQ277Ac3MowjL5i6u7T83+jQUavugkNf6 MvPRpNKNr1EWuifXQws+MRNRhe750xzK9JflVCP7bd67Q9s7wzWTitlQ8GiQ3a+TCemT ZH7038LTILHzI7nOIaXM2g/h16eax3zOPz7oxwefB4j+F/ZyR7cQIViBhfj1uVOY0tWB muLlqKDshb6Op2POpneTaDmVAWADft5EX0GnYA/IKiJg0DYe06GRBzxCAcwdgONA63Mx Tri+rqSeasjZer9GYRGBl1KO8T1KY9wtcRVMXFr4Rvi1KGvVQFdX5btkYmlUMxzoWqli X4kA==
X-Gm-Message-State: APjAAAUfVWJci0ubgXkUIOIbqUBdKjL9kh+lKfyh4zDpp/nu9VI4Xgaa XU7W74HRwuupI5CmNpfsNE2Ey85OJzhdDCCAylInV2zv
X-Google-Smtp-Source: APXvYqxrvImyTl0zk0/WmPMlGY2DFBVAFqZWtkn2BZLr83CWusPueG21fFCYz9FDvYQbqM7UllCotccYJSbBbQp4HEE=
X-Received: by 2002:a67:2701:: with SMTP id n1mr25829231vsn.103.1582555917837; Mon, 24 Feb 2020 06:51:57 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Steven Sommars <>
Date: Mon, 24 Feb 2020 08:51:46 -0600
Message-ID: <>
Cc: IETF-Announce <>,,,, "Karen O'Donoghue" <>,
Content-Type: multipart/alternative; boundary="00000000000051ebe2059f5383fe"
Archived-At: <>
Subject: Re: [Ntp] Last Call: <draft-ietf-ntp-using-nts-for-ntp-22.txt> (Network Time Security for the Network Time Protocol) to Proposed Standard
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Feb 2020 14:52:05 -0000

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 ).
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 <> 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
> mailing lists by 2020-02-28. Exceptionally, comments
> may
> be sent to 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
> IESG discussion can be tracked via
> 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