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

Apologies for the (very) late reaction. James, your comments on the
purpose of that paragraph are completely accurate with how I remember
it. As some additional background, this came out of someone (can't
remember who) suggesting on the mailing list they were (or at least
could possibly) using the current reference id for some form of access
filtering.

On Tue, Feb 7, 2023 at 1:39 PM James <james.ietf@gmail.com> wrote:
>
> 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
>