Re: [Ntp] WGLC: draft-ietf-ntp-using-nts-for-ntp

[Harlan Stenn <[e-mail]>]

I am strongly supportive of the goal of providing a replacement for
Autokey, as soon as possible.

As written, I am opposed to the adoption of this proposal, as the
detailed objections and concerns I have repeatedly raised have still not
been addressed.

Off the top of my head, here is a (partial?) summary of my objections:

- we have long earmarked EF type 4 for NTS, and this is still not in the
document as a recommendation for IANA.  In particular, if the proposal
advances as written we would want to see:

|   0x0104   | * NTS Unique Identifier Request              |
|   0x8104   | * NTS Unique Identifier Response             |
|   0x0204   | * NTS Cookie                                 |
|   0x0304   | * NTS Cookie Placeholder                     |
|   0x0404   | * NTS AEEF Request                           |
|   0x8404   | * NTS AEEF Response                          |

(or similar).  There is no good reason to leave it up to IANA to
possibly assign 6 random EFs for this use case.
draft-stenn-ntp-extension-fields (for which I will be trying to post an
update soon) clearly and simply describes this.

- The proposal is too monolithic, and we would all be better served with
a proposal that separates the cookie mechanism and encrypted transfers
into separately-usable mechanisms.  There may be other similar cases as
well, but my brain is too fuzzy right now to think more about this.

- It creates a separate TCP service/port specifically for NTS key
exchange.  This is wasteful in general, and would be better served by
folks collaborating on:

 draft-stenn-ntp-tcp-services
 draft-stenn-ntp-tcp-services-keyexchange

- The proposal uses multiple Cookie and Cookie Placeholder messages (as
I recall - see my other message about the cold I'm still recovering
from) instead of having a single Cookie and Cookie Placeholder message
that supports multiple entries.  This would not be an issue if 7822 did
not specify a 28-octet minimum final EF size, or if
draft-stenn-ntp-extension-fields was implemented (or being considered,
even).

- It only supports client/server mode, and it does so in a way for which
adding support for symmetric and [mb]*cast modes had been demonstrated
to be problematic.  We need an encompassing solution, and this isn't it.

It would not surprise me at all to discover issues I have forgotten to
list above that are in my previous messages on this topic.

I'm sorry I haven't had the resources to once again re-study and re-list
my objections to this proposal.

Dave Mills has posted several papers about the above problems including
a proposed solution, but for whatever reasons, for years we have
continued to pursue this increasingly limited solution instead of
working towards a better/more functional solution.

As I said in an earlier message, Dave is currently unable to receive or
send email messages, so he apparenetly can't participate in this WGLC.

-- 
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!