IETF Logo Mail Archive

Re: [Ntp] I-D Action: draft-ietf-ntp-ntpv5-requirements-01.txt

James <james.ietf@gmail.com> Tue, 07 February 2023 12:39 UTC

Return-Path: <james.ietf@gmail.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F9FC1522AF for <ntp@ietfa.amsl.com>; Tue, 7 Feb 2023 04:39:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkF-IUl6krip for <ntp@ietfa.amsl.com>; Tue, 7 Feb 2023 04:39:48 -0800 (PST)
Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB06FC15171E for <ntp@ietf.org>; Tue, 7 Feb 2023 04:39:48 -0800 (PST)
Received: by mail-ej1-x62f.google.com with SMTP id m2so42797485ejb.8 for <ntp@ietf.org>; Tue, 07 Feb 2023 04:39:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tjy+qRrn1YvtnUndke13tau5eRBvUsUbhNz/btmAZSE=; b=k/EOYpE+NONk1JewrAd4Mz/+AIKv0iDKTzYUy8WfhO3iYM0/8TB/WBJIXq1GtAzbAr HTfqkmqtC/CNDVp8oYh0T14UlrjLwFBRBpWh699GVq1GFH6C633+NUoWLoDQnbxkk3q6 v+JFnlxGqEMUKvs1aL5b+YAiUvYWaoz0/GZBUbBcEM0ZIXjPmsKCN4ohkwnQzUUMtvXG 65JF9qpPRlkNr25+HEvogg+Ew4zgt/fpeQqpXZD2Pd4u6m5cwmjVP1J1dYYKimoSF7+D qdGuP6i3mFLwAqcTiWysaGKFhY5+RkPql/hlH/OiQzBHx0hCHgr4Y3LTfhrejpHs54Q9 cA1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=tjy+qRrn1YvtnUndke13tau5eRBvUsUbhNz/btmAZSE=; b=kayI2hPrb3OmMJOGlx2i3WoG6QR95fiJDpvBQlN1H1AghuUKf+H+kaapjRyVSaBVwx eh3r1j0eOqF4QU/k3qq27HYz2/PcEDQO8SjV/RuZ7p317rmT2NI/uVHWQuWKX8W16gdI 3XIaWnhglZCR3dx4RETB5d4yqQAct+zA8akGZQGkbGPDcE/ug+us7tuSlj3Zof/lQsdp FiFWLhVUbbe9DVzhKexrpERAxnKJY403mY1Ph7GinrDq3M0VSSs9jKpgfotiDvk/P6/w JGNyPua+ZTZA6k3KD/CZsujBB8TG4Org8ZW+s5i5tsKMttIlLAHfP4Ly+lU6/WFLS8il 7k1Q==
X-Gm-Message-State: AO0yUKUYb/m7pWNIfqHzr23wc8dt7jc0SdPN+fJVaPikbqAOp0IQZiDi 9SshS/VztwIBigBMjl9RlyBmJhj3vUGadQ==
X-Google-Smtp-Source: AK7set9mpxMIioOSh74UMI+wEn9UWylqR2LXfxbY4pZ8n9CUClbVYW5kzQk0LBL1WgE5DeqUSme9fg==
X-Received: by 2002:a17:906:8052:b0:87f:2d81:1d28 with SMTP id x18-20020a170906805200b0087f2d811d28mr3178767ejw.66.1675773587427; Tue, 07 Feb 2023 04:39:47 -0800 (PST)
Received: from smtpclient.apple ([145.15.244.173]) by smtp.gmail.com with ESMTPSA id 13-20020a170906004d00b008512e1379dbsm6911170ejg.171.2023.02.07.04.39.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Feb 2023 04:39:47 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.400.51.1.1\))
From: James <james.ietf@gmail.com>
In-Reply-To: <Y8/frEvjBTeFwG1k@localhost>
Date: Tue, 07 Feb 2023 13:39:32 +0100
Cc: David Venhoek <david@venhoek.nl>
Content-Transfer-Encoding: quoted-printable
Message-Id: <D07EFED9-DF04-4F7A-8FE7-DF1F8ACADCC3@gmail.com>
References: <167406509279.8060.1009165838491116090@ietfa.amsl.com> <Y8/frEvjBTeFwG1k@localhost>
To: ntp@ietf.org, Miroslav Lichvar <mlichvar@redhat.com>
X-Mailer: Apple Mail (2.3731.400.51.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/2h_UohB6QNpbc8WpX1BpOvUUdBs>
Subject: Re: [Ntp] I-D Action: draft-ietf-ntp-ntpv5-requirements-01.txt
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Feb 2023 12:39:49 -0000

Miroslav,

Thanks for reviewing the document, and apologies for my delay in response.

See inline.

- J

> On 24 Jan 2023, at 14:39, Miroslav Lichvar <mlichvar@redhat.com> wrote:
> 
> On Wed, Jan 18, 2023 at 10:04:52AM -0800, internet-drafts@ietf.org wrote:
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Network Time Protocols WG of the IETF.
>> 
>>        Title           : NTPv5 use cases and requirements
>>        Author          : James Gruessing
>>  Filename        : draft-ietf-ntp-ntpv5-requirements-01.txt
> 
> The new version added the following paragraph:
> 
>   An additional identifier mechanism MAY be considered for the
>   purposes of client allow/deny lists, logging and monitoring. Such a
>   mechanism, when included, SHOULD be independent of any loop
>   avoidance    mechanism, and authenticity requirements SHOULD be
>   considered. 
> 
> It's not very clear to me what feature of the protocol is this
> supposed to allow or prevent. Any examples?

J: My interpretation of the text David provided (also based on our discussions) is to ensure a decoupling of access control (allow/deny list) from loop detection functionality as the two are orthogonal concepts and should have no dependency. The choice of MAY is that it's entirely optional for this capability to be provided in the protocol specification, recognising it's additional (optional) bytes on the wire, and potential complexity.

David: Is this right? Or do you have a differing view?

> 
> In 5.1. there is:
>   The risk that an on-path attacker can delay packets between a
>   client and server exists in all time protocols operating on
>   insecure networks and its mitigations within the protocol are
>   limited for a clock which is not yet synchronised.
> 
> I think I suggested this before. It would be good to add a requirement
> here for the protocol to MUST be able to prevent attackers from
> injecting unlimited offsets to the measurements, i.e. not allow the
> broadcast mode in NTPv5. We should support only the most secure mode
> (client-server).

J: Whilst I agree with this, at the last interim we had an unresolved discussion about which modes should/shouldn't be in scope. I've raised https://github.com/fiestajetsam/draft-gruessing-ntp-ntpv5-requirements/issues/14 but haven't had feedback yet.

> -- 
> Miroslav Lichvar
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp

v2.23.0 | Report a Bug | By Email