Re: [Ntp] Magnus Westerlund's Discuss on draft-ietf-ntp-using-nts-for-ntp-23: (with DISCUSS and COMMENT)

[Marcus Dansarie <[e-mail]>]

Hi Magnus!

Thank you for your work in reviewing the draft. We have carefully gone
over all your comments and DISCUSS points. Each of them is addressed below.

Kind regards,
Marcus Dansarie

On 2020-03-18 15:25, Magnus Westerlund via Datatracker wrote:
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-ntp-using-nts-for-ntp-23: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Two issues I would like to discucss:
> 
> 4.1.7.  NTPv4 Server Negotiation
> The
>    contents of the string SHALL be either an IPv4 address, an IPv6
>    address, or a fully qualified domain name (FQDN).
> 
> The client MUST NOT send more than one
>    record of this type.
> 
> I get there are assumptions about which address family to use for this record.
> Is it assumed that one the KE server will chose what address family the
> clien'ts request is coming in over? Do there need to be more discussion of this
> assumption in the document? For example an client indication of an IPv4 address
> can the server respond with an IPv6? And maybe even more relevant, what if the
> client has included an IPv6 address in the field in the request, even if the
> connection to the KE is over IPv4. I would appreciate some clarification or
> recommendation on how to select what family to use so that the protocol achieve
> the least amount of surprise here.
> 
> Secondly, I struggle to full understand the implementation requirements of the
> replay protection.

Section 4.1.7. has been updated to rectify this.

> 5.7:
>       Exactly one Unique Identifier extension field which MUST be
>       authenticated, MUST NOT be encrypted, and whose contents MUST NOT
>       duplicate those of any previous request.
> 
> Is the last "MUST NOT" really a MUST NOT in the most strict sense? It could
> require a client to keep a history of all used Unique Identifiers since it
> started. I think that would be a significant state management task for the
> client. I would expect that a client could work well with a window of N
> packets, where N is in the range hundreds to thousands and using a RNG for the
> Unique Id field. By tracking requests sent, their timestamp and Unique Id the
> client wouldn't the client be able to protect against replays? Discard any
> unknown unique IDs, discard any second reception of Unique IDs. This also
> depends on that replay packets outside of the window can be detected even if
> the RNG generated a duplicate ID. I assume so is possible based on that the NTP
> timestamps that are authenticated will be outside of the window of what is
> acceptable and not match the request.
> 
> To summarize can we get some more clarity on how the client process of replay
> protection.

Section 5.7. has been updated to clarify this. Section 9.6 (Random
Number Generation) has been removed.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Section 5.6:
> 
> The
>    contents of the string SHALL be either an IPv4 address, an IPv6
>    address, or a fully qualified domain name (FQDN).
> 
> The
>    contents of the string SHALL be either an IPv4 address, an IPv6
>    address, or a fully qualified domain name (FQDN).
> 
> This is nit-picking, but shouldn't this be explicit that the zero-padding is at
> the end of respective field?

The draft has been updated to clarify this.