Subject: [TICTOC] Mirja Kühlewind's Discuss on draft-ietf-tictoc-multi-path-synchronization-05: (with DISCUSS and COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Thu, 22 Sep 2016 04:52:42 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tictoc-multi-path-synchronization-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-multi-path-synchronization/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"Each NTP clock has a set of N IP addresses. The assumption is that
      the server information, including its multiple IP addresses is
      known to the NTP clients."

A protocol specification should not make this assumption but describe a
mechanism how a client gets to know about these IP addresses. However,
this draft does not read like a protocol specification anyway; it rather
reads like an informational document leaveraging existing mechanisms to
use multiples pathes (see further below). 

Further, this draft claims in the abstract that this mechanism could
enhance security which is not further discussed (should be added to the
security considerations section!). However, I would guess that it depends
on the choosen combining algorithm if it enhances security or not (or
even worsens it). If so that really needs to be further discussed!

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This drafts reads rather like a research paper than an RFC. Especailly
saying that "The Multi-Path Precision Time Protocol
   (MPPTP) and Multi-Path Network Time Protocol (MPNTP) define an
   additional layer that extends the existing PTP and NTP without the
   need to modify these protocols. "
is completely overstating. I really don't see that this doc defines new
protocols or a new layer. I would strongly recommend to not give the
describe mechanisms a name (like Multi-Path Precision Time Protocol 
(MPPTP) and Multi-Path Network Time Protocol (MPNTP)) as these are no
protocols. I further recommend to publish this document instead as an
informational RFC that describes how to leverages multiple pathes without
protocol changes. 

Also section 6 that only gives references to other docs would be
acceptable for an informational draft but for a protocol spec. A spec
should provide an implementation recommendation by provding a default
algorithm.

Some editorial commenta:

I would recommend to shorten the abstract by removing or moving the first
part, potentially into the introduction instead, and only leave this
part:

"This document describes a multi-path approach to the Network Time
Protocol (NTP) and the
   Precision Time Protocol (PTP) over IP networks, allowing the protocols
to run concurrently over
   multiple communication paths between the master and slave clocks. The
   multi-path approach can significantly contribute to clock accuracy,
   security and fault tolerance."

Also section 3 and 4 could be completely removed or shorten to 2-3
paragraph that could also be integarted into the introdcution.

---

From: Karen O'Donoghue <[email-masked]>
Date: Thu, 22 Sep 2016 12:13:38 +0000

Question for clarification: 

We proposed this draft with a status of "Experimental" with the intention that further analysis and development would be done before proposing any standards track protocol solutions (or an information RFC). Given this metric, I thought it was reasonable for this to seem more like research. Was this taken into account in your analysis of the document? 

Regards,
Karen O’Donoghue (tictoc co-chair)

> On Sep 22, 2016, at 7:52 AM, Mirja Kuehlewind <[email-masked]> wrote:
>

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Thu, 22 Sep 2016 14:32:01 +0200

Hi Karen,

not sure what you mean by „seem more like research“, however, both Standards track documents and experimental documents are protocol specifications (or defining other kinds of normative information; but in this case we seem to speak about a protocol spec). The difference between experimental and standards track is that there is less deployment (potentially none) and therefore there are open questions that might influence the protocol design. These open questions should be mentioned at best in an own section. If the experiment is successful, one could either adapt the specification based on the achieved results or even move the document forward to standards track without any modification if the experiment showed no problems that need to be fixed. As I said, both types should be written as specs, just the level of maturity might be different. ‚Just‘ putting a research paper into a draft is usually not sufficient as research papers are written with a different target and different target audience.

There is no transition from experimental to informational. If a doc is only informational, in the sense that it does not specify a protocol or defines any other normative information, it should be informational from the beginning.

Does that help to clarify things?

Mirja

> Am 22.09.2016 um 14:13 schrieb Karen O'Donoghue <[email-masked]>:
> 
>

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 26 Sep 2016 15:34:42 +0100

On 22/09/2016 12:52, Mirja Kuehlewind wrote:
> mechanism how a client gets to know about these IP addresses.

The base NTP protocol gets the time server addresses by configuration, 
and thus
the assumption seems reasonable.

There is something of a chicken and egg problem here since the IP
address of the time servers needs to be securely known, but to run a 
security
protocol needs knowledge of the time. This observation may well point to a
security issue with the popular use of anycast domain names in NTP
configuration since it is difficult to see how you authenticate DNS without
prior access to time to validate a certificate from the DNS server.

You might encourage the IETF to look at this conundrum, and indeed the IOT
folks would like a solution, but I don't think you can burden this draft 
with
solving the problem.

Regards

Stewart

---

From: Tal Mizrahi <[email-masked]>
Date: Tue, 27 Sep 2016 06:59:14 +0000

Hi Mirja,

Many thanks for the thorough review.

>mechanism how a client gets to know about these IP addresses. However, this
>draft does not read like a protocol specification anyway; it rather reads like an
>informational document leaveraging existing mechanisms to use multiples
>pathes (see further below).

[TM] I agree that the current draft is not a protocol specification. It describes an approach that uses multiple paths without modifying the protocols. Specifically, the abstract says: "This document describes a multi-path approach to PTP and NTP over IP networks, allowing the protocols to run concurrently over multiple communication paths between the master and slave clocks."
Looking over the document, I agree that in some cases the document implies that it defines a protocol. Would it address your concern if we revised the text so as not to imply that we are defining a protocol?

>Further, this draft claims in the abstract that this mechanism could enhance
>security which is not further discussed (should be added to the security
>considerations section!). However, I would guess that it depends on the
>choosen combining algorithm if it enhances security or not (or even worsens
>it). If so that really needs to be further discussed!

[TM] Agreed. Actually we received a similar comment from Watson, the SEC-DIR reviewer, and plan to update the text of the security considerations section to the following:

The security aspects of time synchronization protocols are discussed in detail in [TICTOCSEC]. The methods describe in this document propose to run a time synchronization protocol through redundant paths, and thus allow to detect and mitigate man-in-the-middle attacks, as described in [DELAY-ATT]. It should be noted that when using multiple paths, these paths may partially overlap, and thus an attack that takes place in a common segment of these paths is not mitigated by the redundancy. Moreover, an on-path attacker may in some cases have access to more than one router, or may be able to migrate from one router to another. Therefore, when using multiple paths it is important for the paths to be as diverse and as independent as possible, making the redundancy scheme more tolerant to on-path attacks.

[TM] Your point about the combining mechanism is well taken, and we propose to add the following paragraph to Section 6:

The combining algorithm should be chosen carefully based on the system properties, as different combining algorithms provide different advantages. For example, some combining algorithms (e.g., [NTP], [DELAY-ATT]) are intended to be robust in the face of security attacks, while other combining algorithms (e.g., [KALMAN]) are more resilient to random delay variation. 

Best regards,
Tal.

>-----Original Message-----
>From: Mirja Kuehlewind [mailto:[email-masked]]
>Sent: Thursday, September 22, 2016 2:53 PM
>To: The IESG
>Cc: [email-masked]; tictoc-
>[email-masked]; [email-masked]; [email-masked]
>Subject: Mirja Kühlewind's Discuss on draft-ietf-tictoc-multi-path-
>synchronization-05: (with DISCUSS and COMMENT)
>
>When responding, please keep the subject line intact and reply to all email
>addresses included in the To and CC lines. (Feel free to cut this introductory
>paragraph, however.)
>
>
>mechanism how a client gets to know about these IP addresses. However, this
>draft does not read like a protocol specification anyway; it rather reads like an
>informational document leaveraging existing mechanisms to use multiples
>pathes (see further below).
>
>Further, this draft claims in the abstract that this mechanism could enhance
>security which is not further discussed (should be added to the security
>considerations section!). However, I would guess that it depends on the
>choosen combining algorithm if it enhances security or not (or even worsens
>it). If so that really needs to be further discussed!
>
>
>This drafts reads rather like a research paper than an RFC. Especailly saying
>that "The Multi-Path Precision Time Protocol
>Also section 6 that only gives references to other docs would be acceptable
>for an informational draft but for a protocol spec. A spec should provide an
>implementation recommendation by provding a default algorithm.
>
>Some editorial commenta:
>
>   Precision Time Protocol (PTP) over IP networks, allowing the protocols to
>run concurrently over