Subject: [Ntp] some comments on the NTS4NTP-Draft09

From: Martin Langer <[email-masked]>
Date: Fri, 11 Aug 2017 11:34:54 +0200

Hi all,

At first, I wanted to tell you briefly that the new NTS implementation will start next week. I have some points/comments on the NTS4NTP-Draft09 that I wanted to mention in this way. Therefore, the content is primarily directed at Daniel Franke.
In advance, I'm in Japan for the next 3 weeks and will probably not be able to respond to comments or emails. I ask for understanding.

=================================================================================
NTS4NTP-Draft09
=================================================================================

1. confusing term "ntp/4"
============================================================

page 10 (chapter 5.1.5, 2nd section):
-----------------------------------------
[...] If the NTS Next Protocol Negotiation record offers "ntp/4",this record MUST be included exactly once. [...]

page 11 (chapter 5.1.5, 4th section):
-----------------------------------------
[...] and the server accepts the "ntp/4" protocol in its NTS Next Protocol Negotiation record [...]

page 11 (chapter 6.1, 1st section):
-----------------------------------------
[...] Following a successful run of the NTS-KE protocol wherein "ntp/4" is selected as a Next Protocol [...]

remark:
-----------------------------------------
"ntp/4" is the same term as in the TLS ALPN extension (see: page 18, chapter 8):

[...] IANA is requested to allocate the following two entries in the Application-Layer Protocol Negotation (ALPN) Protocol IDs registry: [...] Protocol: Network Time Protocol, version 4 Identification Sequence: 0x6E 0x74 0x70 0x2F 0x34 ("ntp/4") [...]

But the NTS Next Protocol Negotiation record contains IDs (e.g. 0x00 for 'Network Time Protocol version 4'; see table at page 21) and not the term 'ntp/4'. This can confusing some readers.

2. Network Byte Order / Host Byte Order
============================================================

page 8 (chapter 5, 5th section):
-----------------------------------------
[...] Record Type: A 15-bit integer in network byte order (from most-to-least significant, its bits are record bits 7-1 and then 15-8). [...]

remark:
----------------------------------------- 
Why 7-1 and then 15-8? Are we use the Little Endian format for the 'Record Type' only or for the whole record? Why we don't use Big Endian?

3. general comment
============================================================

page 12 (chapter 6.1, 2nd section):
-----------------------------------------
[...] The per-association context value SHALL consist of the following five octets: The first two octets SHALL be zero.[...]

remark:
----------- 
My first thought was: why? At first it was a magic number for me. The solution is here: chapter 5.2: 
[...] and MUST begin with the two-octet Protocol ID which was negotiated as a Next Protocol. [...]

I think this should be mentioned again or referenced to the corresponding table (chapter 8).

4. general comment
============================================================

page 13 (chapter 6.5, 2nd section):
-----------------------------------------
[...] This length requirement serves to ensure that the response will not be larger than the request, in order to improve timekeeping precision and [...]

remark:
----------- 
Does it really improve the timekeeping? I think the idea is to reduce the asymmetry if the request and response message have the same size. 
But client and server may have different performance and therefore the processing speed per NTP Package is different too. ...it's just a thought

5. alternative proposal
============================================================

page 20 (chapter 8, 1st section):
-----------------------------------------
[...] Type Number (REQUIRED): An integer in the range 0-32767 inclusive [...]

better?:
----------- 
[...] Type Number (REQUIRED): An 15 bit integer in the range 0-32767 inclusive [...]

....not 16 bit, because we use a critical bit in our records (first bit)

6. some problems with 'The NTS Authenticator and Encrypted Extensions extension' (page 14, chapter 6.6)
============================================================

field description:
-----------------------------------------
'Nonce lenght': We should mention that the value is to be interpreted as 'unsigned int'.

'Nonce': At first I had some trouble to understand where the nonce comes from and which length we use. Now I know it, but maybe we should add some more information to this field.
perhaps from these: [...] Nonce: a nonce as required by the negotiated AEAD Algorithm. [...] to these: [...] Nonce: a new generated nonce whose length and format is determined by the negotiated AEAD algorithm (RFC 5116, chapter 3.2). [...]

'Chipertext': Some readers (students in my team) had difficulties to understand this field. All of them thought, that this field contains an encrypted version of the whole NTP package. And this is wrong. I think the problem is this line: [...] authentication tag in addition to the actual ciphertext. [...]. Well, if readers do not know exactly how AEAD works, then this leads to strong understanding problems at this point, since the terms 'authentication tag' and 'ciphertext' seem not known. I think we should add a reference (RFC 5116 --> AEAD) or some information about this terms ('authentication tag' is like a MAC and 'ciphertext' contains optional Extension Fields and can be absent if no Extension Fields are encrypted.). Maybe confuses the field name 'Chipertext' too.

'Padding:' This line: [...] so that implementations can unambiguously delimit the end of the ciphertext from the start of the padding [...] can be difficult to. In the beginning I did not know how this should work. We should say that implementations can read the last octet of this extension content, to find out how big the padding is.

Furthermore we should change this line:
[...] requirement that (in the absence of a legacy MAC) extensions have a total length in octets (including the four octets for the type and length fields) [...]

in this:
[...] requirement that (in the absence of a legacy MAC) NTP extensions have a total length in octets (including the four octets for the type and length fields) [...]

--------------------------------

[...] P: The plaintext SHALL consist of all (if any) extensions to be encrypted. [...] 

Which format? Typical NTPv4 Extension Fields or another format? We should define that. We should also mention that only this content is encrypted (not the content of parameter 'A'). 
If we don't want encrypt anything (default case), then this parameter is empty.

============================================================

Please let me know if you have problems to understand my *english*.

Best regards,
Martin
_______________________________________________
ntp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ntp

---

From: Dieter Sibold <[email-masked]>
Date: Tue, 29 Aug 2017 08:55:10 +0000

I want draw attention to Martin Langer’s technical question on draft-ietf-ntp-using-nts-for-ntp, which he sent at 11th August.

From: ntp [mailto:[email-masked]] On Behalf Of Martin Langer
Sent: Friday, August 11, 2017 11:35 AM
To: [email-masked]
Subject: [Ntp] some comments on the NTS4NTP-Draft09

Hi all,

remark:

remark:

3. general comment

remark:
-----------

4. general comment

remark:
-----------

5. alternative proposal

better?:
-----------

field description:

in this:

Best regards,
Martin

---

From: Dieter Sibold <[email-masked]>
Date: Tue, 29 Aug 2017 08:55:10 +0000

Hi all,

remark:

remark:

3. general comment

remark:
-----------

4. general comment

remark:
-----------

5. alternative proposal

better?:
-----------

field description:

in this:

Best regards,
Martin

---

From: Daniel Franke <[email-masked]>
Date: Tue, 29 Aug 2017 14:25:57 -0400

Sorry for overlooking this earlier.

On 8/11/17, Martin Langer <[email-masked]> wrote:

> [...] IANA is requested to allocate the following two entries in the
> Application-Layer Protocol Negotation (ALPN) Protocol IDs registry: [...]
> Protocol: Network Time Protocol, version 4 Identification Sequence: 0x6E
> 0x74 0x70 0x2F 0x34 ("ntp/4") [...]
>
> But the NTS Next Protocol Negotiation record contains IDs (e.g. 0x00 for
> 'Network Time Protocol version 4'; see table at page 21) and not the term
> 'ntp/4'. This can confusing some readers.

Yup, this is an outright error. I'll fix it in Git momentarily.

> 3. general comment

I'll edit to clarify these.

> [...] This length requirement serves to ensure that the response will not be
> larger than the request, in order to improve timekeeping precision and
> [...]
>
>
> remark:
> -----------
> Does it really improve the timekeeping? I think the idea is to reduce the
> asymmetry if the request and response message have the same size.
> But client and server may have different performance and therefore the
> processing speed per NTP Package is different too. ...it's just a thought

I'm led to believe Prof. Mills did some experiments at one point and
found a non-zero impact from using asymmetrically-sized packets. I
guess a citation here would help. Harlan/Dave, do you know of any
academic reference I can point at to support this claim?

> 5. alternative proposal

I disagree that this is an improvement. At best it's redundant since
0-32767 already covers the full range of possible 15-bit values. But
more importantly, we should be maintaining separation of concerns
between the IANA registry and the protocol specs which make reference
to it. IANA is just recording the number. It's up to protocol
specification to define how it should be encoded.

> extension' (page 14, chapter 6.6)

I agree. I've just changed this in git.

> 'Nonce': At first I had some trouble to understand where the nonce comes
> from and which length we use. Now I know it, but maybe we should add some
> more information to this field.
> perhaps from these: [...] Nonce: a nonce as required by the negotiated AEAD
> Algorithm. [...] to these: [...] Nonce: a new generated nonce whose length
> and format is determined by the negotiated AEAD algorithm (RFC 5116, chapter
> 3.2). [...]

I don't quite like the wording you propose but I'll see if I can make
some clarification along those lines.

> 'Chipertext': Some readers (students in my team) had difficulties to
> understand this field. All of them thought, that this field contains an
> encrypted version of the whole NTP package. And this is wrong. I think the
> problem is this line: [...] authentication tag in addition to the actual
> ciphertext. [...]. Well, if readers do not know exactly how AEAD works, then
> this leads to strong understanding problems at this point, since the terms
> 'authentication tag' and 'ciphertext' seem not known. I think we should add
> a reference (RFC 5116 --> AEAD) or some information about this terms
> ('authentication tag' is like a MAC and 'ciphertext' contains optional
> Extension Fields and can be absent if no Extension Fields are encrypted.).
> Maybe confuses the field name 'Chipertext' too.

The use of 'ciphertext' here comes straight out of RFC 5116, which in
turn comes out of Rogaway's 2002 paper in which he coins "AEAD". I
agree it's a little confusing if you're not steeped in the relevant
literature but I think any departure from the RFC 5116 terminology
would do more harm than good.

>
>
> 'Padding:' This line: [...] so that implementations can unambiguously
> delimit the end of the ciphertext from the start of the padding [...] can be
> difficult to. In the beginning I did not know how this should work. We
> should say that implementations can read the last octet of this extension
> content, to find out how big the padding is.

Fair enough.

> [...] requirement that (in the absence of a legacy MAC) extensions have a
> total length in octets (including the four octets for the type and length
> fields) [...]
>
> in this:
> [...] requirement that (in the absence of a legacy MAC) NTP extensions have
> a total length in octets (including the four octets for the type and length
> fields) [...]

This interacts somewhat with Harlan's request to say "extension field"
rather than just "extension".  I've done that now, and I'll go through
RFC 7822 again to make sure we're using consistent terminology in this
and other places.

> Which format? Typical NTPv4 Extension Fields or another format? We should
> define that. We should also mention that only this content is encrypted (not
> the content of parameter 'A').

Typcial NTPv4 EFs. I'll add a sentence or two to clarify this.

> Please let me know if you have problems to understand my *english*.

Your English is completely fine.

---

From: Daniel Franke <[email-masked]>
Date: Tue, 29 Aug 2017 14:25:57 -0400

Fair enough.

---

From: Daniel Franke <[email-masked]>
Date: Tue, 29 Aug 2017 15:58:32 -0400

> specification to define how it should be encoded.

I just realized that in some other entries I'm not following my own
advice. I'll change those.

---

From: Daniel Franke <[email-masked]>
Date: Tue, 29 Aug 2017 15:58:32 -0400

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 30 Aug 2017 09:53:31 +0200

> academic reference I can point at to support this claim?

If no citation is found, I think it is safe to say that a fundamental
property of most networks is that longer packets take longer to
transmit and receive. NTP assumes that network delay is symmetric, so
the packet size must be symmetric.

For instance, on 1Gb ethernet the delay should increase by 1
nanosecond per bit after reaching the minimum frame size. If the size
is asymmetric, the asymmetry in delay will multiply with the number of
transmissions (including all routers and switches not using
cut-through switching) on the path between the client and server. Of
course, this would normally not be the only source of asymmetry and
symmetric size alone doesn't guarantee accurate measurements.

It is possible to measure the asymmetry. Here is a graph of offset
of a client directly connected to a server on 1Gb ethernet. The clock
was synchronized using symmetric NTP packets. The client also had a
"noselect" association with the server, which had requests longer by
28 octets (a dummy extension field) than responses. The expected
offset between the two associations is 28 * 8 / 2 = 112 nanoseconds.

http://i.imgur.com/hCP9rU2.png

-- 
Miroslav Lichvar

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 30 Aug 2017 09:53:31 +0200

-- 
Miroslav Lichvar

---

From: [email-masked]
Date: Wed, 30 Aug 2017 17:21:36 +0200

I agree with Miroslav. Symmetric packets sizes are also helpful if you 
want to calibrate dedicated network connection for systematic offsets. 

Dieter

"ntp" <[email-masked]> schrieb am 30.08.2017 09:53:31:

> Von: Miroslav Lichvar <[email-masked]>
> An: Daniel Franke <[email-masked]>
> Kopie: [email-masked], Martin Langer <[email-masked]>
> Datum: 30.08.2017 09:53
> Betreff: Re: [Ntp] some comments on the NTS4NTP-Draft09
> Gesendet von: "ntp" <[email-masked]>
>

---

From: [email-masked]
Date: Wed, 30 Aug 2017 17:21:36 +0200

Dieter

---

From: Martin Langer <[email-masked]>
Date: Thu, 31 Aug 2017 15:26:14 +0200

Hello all,

I'm back now. I have not managed to read all the mail, but thanks for the replies. I think I found another minor problem that I wanted to address.
The following case: During the NTS-KE the client sends various record types to the server. The 'NTS Next Protocol Negotiation' record type contains 2 IDs (ID 0 for NTP/4 and ID 1 for PTP/2). The server will generate one or more cookies in the response message. To do this, the S2C and C2S key must be extracted first.

Now in Section 5.2:

[...]
However, all protocols which utilize NTS-KE MUST conform to the following two rules:

The disambiguating label string MUST be "EXPORTER-network-timesecurity/1".

The per-association context value MUST be provided, and MUST begin with the two-octet Protocol ID which was negotiated as a Next Protocol.
[..]

Indeed, at the moment we use ID 0 for NTP. But which ID is selected when the server supports both protocols (IDs)? 

Best regards, 
Martin

---

From: Martin Langer <[email-masked]>
Date: Thu, 31 Aug 2017 15:26:14 +0200

Hello all,

Now in Section 5.2:

[...]

Best regards, 
Martin