[TICTOC] 答复: The draft for IPsec synchronization security

bixiaoyu <bixiaoyu@huawei.com> Mon, 06 December 2010 09:08 UTC

Return-Path: <bixiaoyu@huawei.com>
X-Original-To: tictoc@core3.amsl.com
Delivered-To: tictoc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 194813A6A0D for <tictoc@core3.amsl.com>; Mon, 6 Dec 2010 01:08:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.139
X-Spam-Level: ***
X-Spam-Status: No, score=3.139 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN+Pj1YqLMHG for <tictoc@core3.amsl.com>; Mon, 6 Dec 2010 01:08:28 -0800 (PST)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 0CC973A6A0A for <tictoc@ietf.org>; Mon, 6 Dec 2010 01:08:28 -0800 (PST)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LD0008AH1EG39@szxga03-in.huawei.com> for tictoc@ietf.org; Mon, 06 Dec 2010 17:08:40 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LD000DGM1EG2X@szxga03-in.huawei.com> for tictoc@ietf.org; Mon, 06 Dec 2010 17:08:40 +0800 (CST)
Received: from b00128395 ([10.111.16.139]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LD0007T31EFL3@szxml06-in.huawei.com> for tictoc@ietf.org; Mon, 06 Dec 2010 17:08:40 +0800 (CST)
Date: Mon, 06 Dec 2010 17:08:39 +0800
From: bixiaoyu <bixiaoyu@huawei.com>
In-reply-to: <7C362EEF9C7896468B36C9B79200D8350CFAD7C916@INBANSXCHMBSA1.in.alcatel-lucent.com>
To: "'Bhatia, Manav (Manav)'" <manav.bhatia@alcatel-lucent.com>
Message-id: <001d01cb9525$2c58b250$8b106f0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset="gb2312"
Content-transfer-encoding: quoted-printable
Thread-index: AcuTWdBBCeJSpUV2SA6xbwdBJa8hFwBwj3PQ
X-Mailman-Approved-At: Mon, 06 Dec 2010 02:49:09 -0800
Cc: tictoc@ietf.org
Subject: [TICTOC] 答复: The draft for IPsec synchronization security
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 06 Dec 2010 09:08:29 -0000

Yes, you are right.

BR


-----邮件原件-----
发件人: Bhatia, Manav (Manav) [mailto:manav.bhatia@alcatel-lucent.com] 
发送时间: 2010年12月4日 10:20
收件人: tictoc@ietf.org
抄送: 'Xie Lei'; bixiaoyu
主题: The draft for IPsec synchronization security

Hi,

My understanding of the problem is as follows:

Currently nodes recognize 1588 packets at the physical ports and generate a
timestamp on RX or TX at a reference point between the PHY and the MAC. This
becomes complicated when we throw Ipsec as the nodes will now no longer be
able to identify the 1588 packets that need to be timestamped/consumed.
Ideally we would like the nodes to recognize all such packets at the port
level and therefore generate a time stamp that can be later used after
decrypting (or verifying Ipsec if its only being used for data integrity
i.e. ESP-NULL). The earlier we recognize the packets that need to be time
stamped the better it is. 

There is also an issue at the intermediate nodes which need to know if there
is a 1588 packet inside the Ipsec tunnel so that it can be prioritized over
the other packets.

I spoke to Rock and others in Beijing about this and I was told that having
a separate Ipsec tunnel exclusively for transporting 1588 packets is not
scalable in the femto architecture and we need a mechanism to unambiguously
identify 1588 packets within an Ipsec tunnel that's also carrying other
service/data traffic. This, thus is the problem that
draft-xu-tictoc-ipsec-security-for-synchronization is attempting to solve.

Is this correct?

Cheers, Manav

--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India

 =