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
**************************************