Richard Laager via devel writes: > The client sending a Server Negotiation record is functionally very > similar to SNI, where a TLS client tells the TLS server the hostname it > is using: https://en.wikipedia.org/wiki/Server_Name_Indication > > This is used with HTTPS to implement virtual hosting--having more than > one named site on the same IP address.
Except that the server address is going to be used via UDP and doesn't have any way to distinguish between "servers at the same address". So the similarity is quite superficial. > That same thing _may_ apply here. I'm not necessarily saying that it > does, but it's something to work through and consider. > > The pool is the obvious example that comes to mind. Clients around the > world configure things like this (ignoring the questions about how you > designate "pool"): > > nts us.nts.pool.ntp.org > nts ca.nts.pool.ntp.org > nts uk.nts.pool.ntp.org > nts fr.nts.pool.ntp.org > nts es.nts.pool.ntp.org > nts de.nts.pool.ntp.org > > Perhaps all the NTS-KE servers are centrally located, so these all > resolve to the same IP(s). Or maybe the US and CA zones are together, > and all the European zones are together. By the client always sending a > name, the NTS-KE server can tell which subpool they are trying to access. That is an interesting idea, however I don't think it works with the wording in the current RFC. If SNI gets used, then the SNI part must be considered outside the scope of the NTS RFC, which would obviously create interoperability problems. Given the fact that the current pool mechanics are entirely in DNS, I don't think they'd have a problem with a different IP for each sub-pool NTS-KE. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
