First round of my stupid questions about NTS

[Achim Gratz]

Eric S. Raymond via devel writes:
> I don't see any requests from Delta to Charlie.  Of course we have
> polling from Alpha to Charlie and (unusually) KODs in the
> other direction.
>
>    Bravo                       Delta
>    NTS client ---------------> NTS server
>       ^                         ^
>       |                         |
>    Alpha                       Charlie
>    NTP client <--------------> NTP server
>
> Does this diagram look correct?

No.  What the heck is an NTS client supposed to be?  The description in
the file suggests it is the NTS-KE described in the RFC, so it clearly
belongs to the server infrastructure (in fact it's the root of trust).
It might be different from the entity serving NTS to actual clients or
the same box or even process, but it is logically a separate entity.

There is no separation of NTS and NTP server either, an NTS server is
supposed to answer plain NTP clients with the old style NTP packets. 

> I'm leaning towards an organization in which the NTS client code lives
> inside ntpd; this would reduce deployment friction slightly.  Is there
> any scenario in which we'd want to run these pieces on different
> hosts?

Yes, if you shard the service among different physical boxes that are
supposed to have the same root of trust.  The figure in the draft pretty
much tells you what this looks like.  It makes most sense in datacenters
I think and will probably not have a lot of traction otherwise.
Although, come to think of it, I could see the NTP pool folks adopting
it in order to unburden their server donors from that part.  Another
consdideration that may tilt the scales towards separating it out is
that NTS-KE has a different load and risk profile than a plain NTS
server without that functionality.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:
http://Synth.Stromeko.net/Downloads.html#WaldorfSounds