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

>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 24.01.2023 um 14:39 in
Nachricht <Y8/frEvjBTeFwG1k@localhost>:
> 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?
> 
> 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).

It's an interesting concept to prevent attackers from injecting packets by
means of the protocol í ½í¸
Maybe the protocol can discard or ignore such packets, but preventing
injection is really hard...

Regards,
Ulrich

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