Re: [TICTOC] TICTOC Digest, Vol 63, Issue 23
STUART VENTERS <stuart.venters@adtran.com> Mon, 12 March 2012 14:44 UTC
Return-Path: <stuart.venters@adtran.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 50F6C21E803E for <tictoc@ietfa.amsl.com>; Mon, 12 Mar 2012 07:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Z1rpImI02uKB for <tictoc@ietfa.amsl.com>; Mon, 12 Mar 2012 07:44:13 -0700 (PDT)
Received: from p02c12o145.mxlogic.net (p02c12o145.mxlogic.net [208.65.145.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8984B21E8035 for <tictoc@ietf.org>; Mon, 12 Mar 2012 07:44:12 -0700 (PDT)
Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by p02c12o145.mxlogic.net(mxl_mta-6.13.0-2) over TLS secured channel with ESMTP id bbb0e5f4.0.62639.00-282.145732.p02c12o145.mxlogic.net (envelope-from <stuart.venters@adtran.com>); Mon, 12 Mar 2012 08:44:12 -0600 (MDT)
X-MXL-Hash: 4f5e0bbc5a54c6e2-c8e9bac6da7e45b3fbd30d3f358e3bfb046e790f
Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::d50f:ceda:4e38:ebf0%15]) with mapi id 14.01.0339.001; Mon, 12 Mar 2012 09:44:36 -0500
From: STUART VENTERS <stuart.venters@adtran.com>
To: "tictoc@ietf.org" <tictoc@ietf.org>
Thread-Topic: TICTOC Digest, Vol 63, Issue 23
Thread-Index: AQHNAEfXOHyxuY+9AkyhLE8PwIEGVpZmuuYw
Date: Mon, 12 Mar 2012 14:44:35 +0000
Message-ID: <1220E2C537595D439C5D026E8375186622038886@ex-mb1.corp.adtran.com>
References: <mailman.780.1331553652.3360.tictoc@ietf.org>
In-Reply-To: <mailman.780.1331553652.3360.tictoc@ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.22.113.98]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)]
X-MAIL-FROM: <stuart.venters@adtran.com>
X-SOURCE-IP: [76.164.174.83]
X-AnalysisOut: [v=1.0 c=1 a=ruWq0YzyRmIA:10 a=72FnoTlqvNcA:10 a=qZHQZMT3ap]
X-AnalysisOut: [YA:10 a=BLceEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:1]
X-AnalysisOut: [0 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=48vgC7mUAAAA:8 a=M5GUcnR]
X-AnalysisOut: [OAAAA:8 a=i0EeH86SAAAA:8 a=aIILdI0ir2pyiF6JEsEA:9 a=EsnQKu]
X-AnalysisOut: [37Axz1tAnFwKYA:7 a=CjuIK1q_8ugA:10 a=-JceEWldcB4A:10 a=lZB]
X-AnalysisOut: [815dzVvQA:10 a=9RRF0ttvEvMA:10 a=hPjdaMEvmhQA:10 a=L2u0e9G]
X-AnalysisOut: [m6todytT2:21 a=81RZIioOf6eJeIjZ:21]
Subject: Re: [TICTOC] TICTOC Digest, Vol 63, Issue 23
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 14:44:14 -0000
2cents worth, One way to deal with a variable latency from the encryption unit might be to separate the encryption calculations into a complicated part which pre-builds an encrypt/decrypt stream and a simple part which just XOR's the prebuilt stream with the freshly timestamped time transfer packet. This still doesn't help the issue of a systematic delay attack. -----Original Message----- From: tictoc-bounces@ietf.org [mailto:tictoc-bounces@ietf.org] On Behalf Of tictoc-request@ietf.org Sent: Monday, March 12, 2012 7:01 AM To: tictoc@ietf.org Subject: TICTOC Digest, Vol 63, Issue 23 If you have received this digest without all the individual message attachments you will need to update your digest options in your list subscription. To do so, go to https://www.ietf.org/mailman/listinfo/tictoc Click the 'Unsubscribe or edit options' button, log in, and set "Get MIME or Plain Text Digests?" to MIME. You can set this option globally for all the list digests you receive at this point. Send TICTOC mailing list submissions to tictoc@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www.ietf.org/mailman/listinfo/tictoc or, via email, send a message with subject or body 'help' to tictoc-request@ietf.org You can reach the person managing the list at tictoc-owner@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TICTOC digest..." Today's Topics: 1. Re: Please Comment on Practical Solutions for Encrypted Synchronization Protocol (Tal Mizrahi) ---------------------------------------------------------------------- Message: 1 Date: Mon, 12 Mar 2012 14:00:44 +0200 From: Tal Mizrahi <talmi@marvell.com> To: Cui Yang <cuiyang@huawei.com>, "tictoc@ietf.org" <tictoc@ietf.org> Subject: Re: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol Message-ID: <74470498B659FA4687F0B0018C19A89C017E9722A03C@IL-MB01.marvell.com> Content-Type: text/plain; charset="gb2312" Hi Yang, > 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. The encryption latency is less relevant than the encryption latency jitter. Depending on the implementation, the latency jitter of the encryption block can be brought down to near-zero-jitter. I agree it is not easy to implement, but there are existing products that do this. Of course I agree that from an implementation perspective it is easier to achieve the same latency in two-step timestamping, and this may be a more delicate way to phrase the idea in the draft. > Since protocols like PTP has accuracy in the range of micro-sec to > mili-sec, and BTW, in some applications PTP accuracy is measured in nanoseconds nowadays. For example, in UMTS (ETSI TS 125 105) the requirement is for 65 ns accuracy. BR Tal. From: Cui Yang [mailto:cuiyang@huawei.com] Sent: Monday, March 12, 2012 11:09 AM To: Tal Mizrahi; tictoc@ietf.org Subject: Re: [TICTOC] Please Comment on Practical Solutions for Encrypted Synchronization Protocol 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<mailto: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> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.ietf.org/mail-archive/web/tictoc/attachments/20120312/7f3ca4cd/attachment.htm> ------------------------------ _______________________________________________ TICTOC mailing list TICTOC@ietf.org https://www.ietf.org/mailman/listinfo/tictoc End of TICTOC Digest, Vol 63, Issue 23 **************************************
- Re: [TICTOC] TICTOC Digest, Vol 63, Issue 23 STUART VENTERS