Subject: [TICTOC] WGLC on NTS: KE over NTP packets or special packets?

From: Sharon Goldberg <[email-masked]>
Date: Thu, 24 Mar 2016 18:15:46 -0400

>
> The main reasoning here was, I believe, that an inherent solution would be
> easier to tailor to a time synchronization protocol's special needs,
> particularly for the additional delays caused by the cryptographic
> operations on time-sensitive packets to be small (and ideally
> symmetrical).
>

OK, that's interesting.
Can you please elaborate on the symmetrical requirement?
And, following some comments of Miroslav I also wonder the following:

1) Will NTS's KE messages be piggybacked on NTP's normal packets with the
usual T1, T2, T3, T4 timestamps?

2) If yes, then during the KE, will the client actually uses these
timestamps to set its clock or inform any of NTP's clock discipline
algorithms?

3) If yes, then I guess you will want to be very careful about the delay
introduced by the public key crypto operations in the KE. How will you deal
with that, in light of the fact that eg. RSA signing is 10x slower than RSA
verification, and RSA encryption is 10x faster than RSA decryption?

Does this even matter?  Maybe it depends on what "symmetrical" means?

When you say symmetrical, do you mean that the time the *query packet is in
flight* (ie T2-T1) should be symmetrical with the time the *response packet
is in flight* (ie T4-T3)?

Or do you mean that that time the server spends processing the packet
should be symmetrical to the time the client spends processing the same
packet?  (This seems problematic if eg. the server is a powerful machine
that does crypto in hardware while the client is a lame machine that does
crypto in software.)

This issue could impact that regular timing exchanges even if it does not
impact the KE.

Thanks,
Sharon

-----"TICTOC" <[email-masked]> schrieb: -----

>An: [email-masked], [email-masked]
>Von: Sharon Goldberg
>Gesendet von: "TICTOC"
>Datum: 23.03.2016 10:07
>Betreff: [TICTOC] WGLC on NTS: Why not run over IPsec?

>
>Dear WG,
>
>Another question, and please forgive me if this was discussed already
>and I missed it.
>
>It would be helpful to know why NTS is not just just running over
>IPsec. (I can see why running NTP over TLS makes little sense, since
>TLS runs over TCP while NTP runs over UDP so everything would
>probably
>break.) But NTP runs over IP. I suppose there are some performance
>hits to using IPsec? What are they?
>
>Thanks,
>Sharon
>

---

From: Kurt Roeckx <[email-masked]>
Date: Fri, 25 Mar 2016 00:25:44 +0100

> Can you please elaborate on the symmetrical requirement?

I assume that he's talking about the time between getting T1 and
sending out the packet, and getting T3 and sending it out would
need about the same delay.

I also assume that to be able to get a very accurate results.  But
if that's the case I think they're going about this the wrong way.
I think for most cases the overhead of the crypto is not going to
have an impact on the results because there is just way more
jitter on the network.  For the cases this matters both sides
should take an additional timestamp when the packet was really sent,
and have a follow up packet that contains the correct time.  For
the cases where this matters, they should already be doing this.

Kurt

---

From: Harlan Stenn <[email-masked]>
Date: Fri, 25 Mar 2016 23:01:14 +0000

The processing of keys *can* happen between T2 and T3, so its effects
are theoretically invisible.

But there is nothing that says we have to return the NTS response in the
next packet.

If a client only wants to use authenticated packets, for some definition
of authenticated, then either the initial packets will need to be
protected by a symmetric key MAC, or the client will either ignore the
packets completely or save them up until a subsequent trusted packet can
be used to lend credence to the earlier unauthenticated timestamps.

H

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 29 Mar 2016 13:11:20 +0200

> usual T1, T2, T3, T4 timestamps?

Yes (if I understand the current drafts correctly).

> timestamps to set its clock or inform any of NTP's clock discipline

Not unless there is some way to authenticate timestamps from the earlier
packets.

> Does this even matter?  Maybe it depends on what "symmetrical" means?

The speed of the RSA operations shouldn't matter as far as the
accuracy of the synchronization is concerned. What matters is the
delay between an NTP server or client capturing the TX timestamp and
the other side capturing the RX timestamp. Asymmetries in that delay
add an error to the measured offset.

The delay includes the calculation of the MAC, the actual transmission
and the network delay. It's a function of the packet length, so there
is a tendency to keep the packets symmetric and short. The delay due
to the MAC calculation can be estimated and compensated (at least one
NTP implementation tries to do that), but the other parts of the delay
I suspect would be very difficult or impossible to estimate.

Wrapping NTP packets in some other protocol like IPsec would create an
additional delay. If it was symmetric or it could be estimated
reliably, perhaps it wouldn't be a problem for accuracy. However, the
size of the state the server would have to keep per client would limit
the maximum number of clients.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 29 Mar 2016 22:50:29 +0000

> Not unless there is some way to authenticate timestamps from the earlier

It's a local policy choice.

If a client chooses to only believe authenticated time, then if no
alternative MAC is available until NTS has completed KE timestamps will
not be used.  If another method (like symmetric key) is available and
enabled, that authentication can cover these initial timestamps.

There are other choices as well, but I think we're talking about
implementation choices and local policy choices.  Let's go the right
distance here, neither too restrictive nor too permissive.

> add an error to the measured offset.

Sure.  But this goes beyond the case of "this packet and this
association".

See my previous message.  We must not *require* that we do the full
crypto operations between T2 and T3 in a busy server that is not
multi-threaded. That will very likely mess up capture timestamps that
are pending receipt while we're doing the crypto operations on the
current packet.

> I suspect would be very difficult or impossible to estimate.

Is there empirical data to support the need for symmetric packet
lengths?  If so, is this a universal condition?

Is there empirical data to show behavioral differences between various
packet lengths?  If so, are these results universally consistent?

> the maximum number of clients.

How do you do IPsec without correct time?

H

---

From: [email-masked]
Date: Wed, 30 Mar 2016 10:21:20 +0200

>need about the same delay.

For the record: yes, this is what I was talking about.

>and have a follow up packet that contains the correct time.

This would be a very clean solution, but my impression was always that NTP did not offer follow-up type messages (as a reminder: for NTS, we try to not require modifications to the specification of the underlying time sync protocol). Am I wrong about his?

> For
>_______________________________________________
>ntpwg mailing list
>[email-masked]
>http://lists.ntp.org/listinfo/ntpwg
>

---

From: Dieter Sibold <[email-masked]>
Date: Wed, 30 Mar 2016 12:41:17 +0200

> Am 30.03.2016 um 10:21 schrieb [email-masked]:
> 
This is correct. NTP as specified in RFC 5905 does not have the concept of a follow up message, like for example PTP. I assume

> TICTOC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tictoc

---

From: [email-masked]
Date: Wed, 30 Mar 2016 12:49:46 +0200

>It's a local policy choice.

I second this, and would like to give the comment that as far as the NTS/NTS-4-NTP specifications are concerned, I envision only two possibilities (one of which might be subdivided):
- NTS can give the statement that for a given NTP message, authenticity and integrity of the NTP header are provided through NTS measures

- NTS can not give the above statement. (This might be subdivided into "no NTS security measures used on this NTP message" or "NTS security measures used on this NTP message, but did not check out", i.e. MAC could not be verified)

Anything beyond that is (and should be) out of our scope for the three existing NTS-related documents.

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 30 Mar 2016 19:27:30 +0200

> This is correct. NTP as specified in RFC 5905 does not have the concept of a follow up message, like for example PTP. I assume

I can't believe that there isn't a draft for this yet.  At least
David Mills has been talking about this years ago.

As far as I know, at least Linux and FreeBSD have support for
hardware timestamping of the packets, but it depends on the
hardware and driver support.

Kurt