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

From: Magnus Westerlund via Datatracker <[email-masked]>
Date: Wed, 18 Mar 2020 07:25:08 -0700

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.

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.

----------------------------------------------------------------------
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?

---

From: "Franke, Daniel" <[email-masked]>
Date: Wed, 18 Mar 2020 14:56:15 +0000

Thanks Magnus. I'll confer with my co-authors on how to handle the address family issue as I don't think it's come up. My first impression on the issue is that the Right Thing is that if the client didn't send any server negotiation record, then the NTS-KE server SHOULD respond with an NTP server address in the same family as the NTS-KE session, if one is available. If the client does send a server negotiation record, then the NTS-KE server SHOULD reply with that same record if it is still valid, and otherwise behave as if the client had not included any server negotiation record.

As to replay protection: it is not expected that the client keep a history of more than one unique identifier. Since unique identifiers are 256-bit random numbers, clients can neglect the probability of collision. NTP clients will generally have only one packet in flight at a time to given server and will discard old packets that arrive out-of-order; this much is how NTP has always worked isn't new to NTS. Would adding a parenthetical of "(except with negligible probability)" to "MUST NOT duplicate those of any previous request" be sufficient to resolve this DISCUSS point?
________________________________________
From: Magnus Westerlund via Datatracker <[email-masked]>
Sent: Wednesday, March 18, 2020 10:25
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; Karen O'Donoghue; [email-masked]
Subject: Magnus Westerlund's Discuss on draft-ietf-ntp-using-nts-for-ntp-23: (with DISCUSS and COMMENT)

5.7:

Section 5.6:

The

The

---

From: Marcus Dansarie <[email-masked]>
Date: Wed, 18 Mar 2020 16:00:52 +0100

> As to replay protection: it is not expected that the client keep a history of more than one unique identifier. Since unique identifiers are 256-bit random numbers, clients can neglect the probabili…

To follow up on Daniel's comment: In response to other reviewers'
comments regarding the unique identifier extension field, the next draft
will contain updated text to clarify this. This should hopefully resolve
your second DISCUSS point. The new draft will be posted shortly.

Kind regards,
Marcus

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Mar 2020 15:08:26 +0000

> -----Original Message-----
> From: Franke, Daniel <[email-masked]>
> Sent: den 18 mars 2020 15:56
> To: The IESG <[email-masked]>; Magnus Westerlund
> <[email-masked]>
> Cc: [email-masked]; [email-masked];
> [email-masked]; Karen O'Donoghue <[email-masked]>; Karen
> O'Donoghue <[email-masked]>
> Subject: Re: Magnus Westerlund's Discuss on draft-ietf-ntp-using-nts-for-
> ntp-23: (with DISCUSS and COMMENT)
> 
> Thanks Magnus. I'll confer with my co-authors on how to handle the address
> family issue as I don't think it's come up. My first impression on the
issue is
> that the Right Thing is that if the client didn't send any server
negotiation
> record, then the NTS-KE server SHOULD respond with an NTP server address
> in the same family as the NTS-KE session, if one is available. If the
client does
> send a server negotiation record, then the NTS-KE server SHOULD reply with
> that same record if it is still valid, and otherwise behave as if the
client had
> not included any server negotiation record.

I think this sounds reasonable.

> 
> As to replay protection: it is not expected that the client keep a history
of
> more than one unique identifier. Since unique identifiers are 256-bit
random
> numbers, clients can neglect the probability of collision. NTP clients
will
> generally have only one packet in flight at a time to given server and
will
> discard old packets that arrive out-of-order; this much is how NTP has
always
> worked isn't new to NTS. Would adding a parenthetical of "(except with
> negligible probability)" to "MUST NOT duplicate those of any previous
> request" be sufficient to resolve this DISCUSS point?

So the MUST NOT is one part, and such an addition would resolve that issue.
However, I still think the replay protection could benefit from a bit more
clarification. Especially as it appears to be easier in some sense than I
would expect from other protocols. However, it appears to be related to a
bit more the NTP protocol functions than the Unique ID field and this could
benefit from have a description. 

Will follow what text changes the other's comment results in. 

Cheers

Magnus Westerlund

---

From: Marcus Dansarie <[email-masked]>
Date: Thu, 19 Mar 2020 18:55:22 +0100

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

> https://datatracker.ietf.org/doc/draft-ietf-ntp-using-nts-for-ntp/

Section 4.1.7. has been updated to rectify this.

> To summarize can we get some more clarity on how the client process of replay

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

The draft has been updated to clarify this.