Re: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Cui Yang <cuiyang@huawei.com> Mon, 12 March 2012 09:19 UTC

Return-Path: <cuiyang@huawei.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 8A6B221F86DD for <tictoc@ietfa.amsl.com>; Mon, 12 Mar 2012 02:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.684
X-Spam-Level:
X-Spam-Status: No, score=-2.684 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq9Y-WpEOiII for <tictoc@ietfa.amsl.com>; Mon, 12 Mar 2012 02:19:28 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E1C0821F86D8 for <tictoc@ietf.org>; Mon, 12 Mar 2012 02:19:13 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R009CALG6FT@szxga05-in.huawei.com> for tictoc@ietf.org; Mon, 12 Mar 2012 17:09:42 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R001NULG6JF@szxga05-in.huawei.com> for tictoc@ietf.org; Mon, 12 Mar 2012 17:09:42 +0800 (CST)
Received: from szxeml209-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AHK04184; Mon, 12 Mar 2012 17:09:23 +0800
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml209-edg.china.huawei.com (172.24.2.184) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 12 Mar 2012 17:08:32 +0800
Received: from SZXEML508-MBS.china.huawei.com ([169.254.6.105]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Mon, 12 Mar 2012 17:09:19 +0800
Date: Mon, 12 Mar 2012 09:09:18 +0000
From: Cui Yang <cuiyang@huawei.com>
In-reply-to: <74470498B659FA4687F0B0018C19A89C017E97229D9C@IL-MB01.marvell.com>
X-Originating-IP: [10.111.49.55]
To: Tal Mizrahi <talmi@marvell.com>, "tictoc@ietf.org" <tictoc@ietf.org>
Message-id: <8CC0CB0BCAE52F46882E17828A9AE2161A172B1D@SZXEML508-MBS.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_WRkD7MVOp6Z9v5T1xiyUAQ)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol
Thread-index: Acz8E0iUW5Z05eDtRseAiVHAxMBZUgDVAA3QAC7qFsA=
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
References: <8CC0CB0BCAE52F46882E17828A9AE2161A032B90@SZXEML508-MBS.china.huawei.com> <74470498B659FA4687F0B0018C19A89C017E97229D9C@IL-MB01.marvell.com>
Subject: Re: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Mon, 12 Mar 2012 09:19:29 -0000

Hi, Tal

Thank you for your comments. Please find my answer in the following:

1.       I am afraid that “The one-step timestamping is not accurate”, is not an assumption but a conclusion, IMO.
As we have analyzed in the Sec 2 in the new draft, encryption time does not affect the two-step timestamping, but does influence the one-step protocol.
Because e1 (encryption time of sync message sent by Master) must be calculated after the timestamp was struck, it definitely introduces errors.
As you mentioned that  some existing products employ the one-step and constant latency method, I think it could be done but depend on the error margin.
Since protocols like PTP has accuracy in the range of micro-sec to mili-sec, and time of encryption or MAC calculation varies on different devices (typically in order of less than mili-sec), it is not easy to implement constant latency method with high accuracy.

While on the other hand, two-step timestamping could  remove the influence of e1, completely. So that , we can focus on dealing with the errors by decryption time.
But I think it is good to note this fact in Sec 2.3 that one existing method for one-step timestamping is to take care of the constant delay, if error margin is acceptable.

The academic paper you noted is interesting and the data that it provides is helpful, as well. We will include it in our reference later (and also for other papers someone commented before). Thanks for reminding me.


2.       The reason you mentioned is one of the motivations we submitted a new draft.
Others are that we would not like to restrict the solution uniquely to “identifier packets” by draft-xu-tictoc-ipsec-security-for-synchronization.  After a lengthy discussion (even continuing now), we feel it necessary clarifying use cases, and comparing all possible practical solutions.

Thank you!

Best regards,
Yang
==================
Yang Cui,  Ph.D.
Huawei Technologies
cuiyang@huawei.com

发件人: Tal Mizrahi [mailto:talmi@marvell.com]
发送时间: 2012年3月11日 17:24
收件人: Cui Yang; tictoc@ietf.org
主题: RE: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Hi Yang,

A couple of comments:

1.       The assumption in the draft is that one-step timestamping is not accurate. However, it is basically a question of implementation. It is possible to perform one-step timestamping and to perform constant-latency-encryption/decryption. Furthermore, there are existing products that do exactly that.
There are a few academic papers that deal with the accuracy of encrypted PTP, for example see A. Treytl, B. Hirschler, “Securing IEEE 1588 by IPsec tunnels - An analysis”.

2.       If I understand the goal of this draft correctly, it appears to be presenting the motivation for draft-xu-tictoc-ipsec-security-for-synchronization. If this is indeed the case, you may want to consider integrating the two drafts.

BR
Tal Mizrahi.

From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of Cui Yang
Sent: Wednesday, March 07, 2012 5:35 AM
To: tictoc@ietf.org
Subject: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol

Hi, all,

I have posted a new draft that discusses the practical solutions for encrypted synchronization protocols.

Since we have discussed a lot on this problem, and the security requirement of synchronization also noted that confidentiality may need protection, especially in case that the confidentiality protection is mandatory. Synchronization should be available when the traffic is encrypted. The influences by the encryption are explained, and several possible solutions have been discussed.
The URL is below, please review and comment.

    Title      : Practical solutions for encrypted synchronization protocol
Author(s)  : Y. Cui,
M. Bhatia,
D. Zhang
Filename   : draft-cui-tictoc-encrypted-synchronization-00.txt
Pages     : 10
Date      : Mar. 1, 2012
   This informational document analyzes the accuracy issues with time
   synchronization protocols when time synchronization packets are
   encrypted during transmission. In addition, several candidate
  solutions on such issues are introduced.

A URL for this Internet-Draft is:
http://datatracker.ietf.org/doc/draft-cui-tictoc-encrypted-synchronization

Thanks,
Yang

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

Yang Cui,  Ph.D.

Huawei Technologies

cuiyang@huawei.com<mailto:cuiyang@huawei.com>