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

Tal Mizrahi <talmi@marvell.com> Tue, 27 September 2016 06:59 UTC

Return-Path: <talmi@marvell.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC28112B369; Mon, 26 Sep 2016 23:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJmY-1z_os12; Mon, 26 Sep 2016 23:59:23 -0700 (PDT)
Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9091412B091; Mon, 26 Sep 2016 23:59:23 -0700 (PDT)
Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u8R6xJcv002454; Mon, 26 Sep 2016 23:59:19 -0700
Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 25ns0j311v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 26 Sep 2016 23:59:19 -0700
Received: from IL-EXCH01.marvell.com (10.4.102.220) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 27 Sep 2016 09:59:14 +0300
Received: from IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36]) by IL-EXCH01.marvell.com ([fe80::5d63:81cd:31e2:fc36%20]) with mapi id 15.00.1104.000; Tue, 27 Sep 2016 09:59:14 +0300
From: Tal Mizrahi <talmi@marvell.com>
To: Mirja Kuehlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>
Thread-Topic: Mirja Kühlewind's Discuss on draft-ietf-tictoc-multi-path-synchronization-05: (with DISCUSS and COMMENT)
Thread-Index: AQHSFMfW/j+wp8czQ0OSMIKN5DpHXqCM5bKA
Date: Tue, 27 Sep 2016 06:59:14 +0000
Message-ID: <93b40adb8bcf40329f091768d05cb389@IL-EXCH01.marvell.com>
References: <147454516251.22463.16980267674502590256.idtracker@ietfa.amsl.com>
In-Reply-To: <147454516251.22463.16980267674502590256.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.4.102.210]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-27_03:, , signatures=0
X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609270127
Archived-At: <https://mailarchive.ietf.org/arch/msg/tictoc/rw--HdxjWm9MrRSKmG-pMuROF1c>
Cc: "odonoghue@isoc.org" <odonoghue@isoc.org>, "draft-ietf-tictoc-multi-path-synchronization@ietf.org" <draft-ietf-tictoc-multi-path-synchronization@ietf.org>, Suresh Krishnan <suresh.krishnan@ericsson.com>, "tictoc-chairs@ietf.org" <tictoc-chairs@ietf.org>, "tictoc@ietf.org" <tictoc@ietf.org>, Watson Ladd <watsonbladd@gmail.com>
Subject: Re: [TICTOC] Mirja Kühlewind's Discuss on draft-ietf-tictoc-multi-path-synchronization-05: (with DISCUSS and COMMENT)
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tictoc/>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2016 06:59:26 -0000

Hi Mirja,

Many thanks for the thorough review.

>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).

[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:ietf@kuehlewind.net]
>Sent: Thursday, September 22, 2016 2:53 PM
>To: The IESG
>Cc: draft-ietf-tictoc-multi-path-synchronization@ietf.org; tictoc-
>chairs@ietf.org; odonoghue@isoc.org; tictoc@ietf.org
>Subject: Mirja Kühlewind's Discuss on draft-ietf-tictoc-multi-path-
>synchronization-05: (with DISCUSS and COMMENT)
>
>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.
>