[ntpwg] Antwort: Re: NTS: DTLS and symmetric mode

[[e-mail]]

Hi Miroslav,

see my comments below.


"ntpwg" <ntpwg-bounces+dieter.sibold=[e-mail]> schrieb am 
01.08.2017 09:38:54:

> Von: Miroslav Lichvar <[e-mail]>
> An: Daniel Franke <[e-mail]>
> Kopie: ntpwg <[e-mail]>
> Datum: 01.08.2017 09:39
> Betreff: Re: [ntpwg] NTS: DTLS and symmetric mode
> Gesendet von: "ntpwg" <ntpwg-bounces+dieter.sibold=[e-mail]>
> 
> On Mon, Jul 31, 2017 at 02:59:30PM -0400, Daniel Franke wrote:
> > On 7/31/17, Harlan Stenn <[e-mail]> wrote:
> > > Is DTLS well-suited for symmetric associations, which require mutual
> > > authentication?
> > 
> > Yes. DTLS supports mutual authentication through the use of client
> > certificates or pre-shared keys.
> 
> That will work nicely for an active-passive association, but I'm still
> not sure about active-active associations. You said the source port of
> a DTLS client is supposed to be random. How will an active peer know
> that an incoming connection corresponds to a peer it has already
> connected to or it's trying to connect to? With symmetric keys/autokey
> it was possible to have multiple associations with the same IP address
> (e.g. multiple machines behind NAT).
> 
> I think a bigger problem with NTP over DTLS might be that timing
> messages are sent on a different port than 123 and are encrypted. This
> makes it incompatible with existing HW/configuration and future NTP
> extensions.
> 
> Here is the list of issues I posted previously (with no response) [1]:
> 
> - no stateless passive mode
> - problematic pairing of DTLS sessions
Daniel considered this question. He provided a discussion in Sec. 4 of the 
current NTS draft (version -09).

> - requires timestamping of messages on a new port
I don't understand the issue of this.

>   - won't work with HW which can timestamp only packets on port 123
>     (or 319)
Yes, but the vast majority of NTP servers and clients don't use HW based 
time stamping. Also note, that HW based time stamping is going to be 
difficult for mode 3 and 4 packets also. This packets are protected by NTS 
extension fields and HW time stamping NICs are not able to calculate the 
NTS AEAD information (at least currently).

>   - will require changes in QoS classification on routers/switches
Yes, this is true.

> - won't work with future NTP extensions for delay corrections in
>   routers/switches
That is probably true. But I don't see the use case for this. Typically 
you apply symmetric mode in a closed environment. If you require the 
additional accuracy of delay corrections in router/switches you would 
apply PTP which already provide these features. 

> 
> [1] http://lists.ntp.org/pipermail/ntpwg/2017-June/003307.html
> 
> -- 
> Miroslav Lichvar
> _______________________________________________
> ntpwg mailing list
> [e-mail]
> http://lists.ntp.org/listinfo/ntpwg

_______________________________________________
ntpwg mailing list
[e-mail]
http://lists.ntp.org/listinfo/ntpwg