Re: [TICTOC] The draft for IPsec synchronization security

Jack Kohn <kohn.jack@gmail.com> Sun, 05 December 2010 01:56 UTC

Return-Path: <kohn.jack@gmail.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 D3CBE3A683D for <tictoc@core3.amsl.com>; Sat, 4 Dec 2010 17:56:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.164
X-Spam-Level:
X-Spam-Status: No, score=-3.164 tagged_above=-999 required=5 tests=[AWL=0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Km4-Dl85qUik for <tictoc@core3.amsl.com>; Sat, 4 Dec 2010 17:56:57 -0800 (PST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id EA7E53A6823 for <tictoc@ietf.org>; Sat, 4 Dec 2010 17:56:56 -0800 (PST)
Received: by iwn40 with SMTP id 40so13641019iwn.31 for <tictoc@ietf.org>; Sat, 04 Dec 2010 17:58:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2Glch0LAToyLtj+1v+Zz5yYXMFADD/QcUfuuQ57uQSk=; b=T7FKGd9AVqVU7a8/se952zp9dDfX78b2FiPjyLvhCXBhr7i+L9fD4VbmmXnFPcjBV1 83epZXRcOyJKWIvk09n1saYiN5T/svPQGB/sMyvkWhf9Q1EcwI3sOTmRaDsfEzrrLDDd f6HpHqZFZE8tEyNLqb7HcnYGUaXY6MAZ0phAM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=U3nCb/B/i0anOPdn4SspJLGZSw2zpR3F25M8bx4SvimQbKPgrhEV5oNfIui7riG5jP VrMI7gfwQc37ewmgOYAkzj/Rs3U1Q7/eOJdEm+NaCRUy29H60PZqGhX4aCXF1gh3Z7ID GoKq2xSM8EnGWM6wLVMXq6CI4CFqH7YBdbB6k=
MIME-Version: 1.0
Received: by 10.231.169.74 with SMTP id x10mr3930241iby.65.1291514296193; Sat, 04 Dec 2010 17:58:16 -0800 (PST)
Received: by 10.231.206.133 with HTTP; Sat, 4 Dec 2010 17:58:16 -0800 (PST)
In-Reply-To: <7C362EEF9C7896468B36C9B79200D8350CFAD7C916@INBANSXCHMBSA1.in.alcatel-lucent.com>
References: <7C362EEF9C7896468B36C9B79200D8350CFAD7C916@INBANSXCHMBSA1.in.alcatel-lucent.com>
Date: Sun, 05 Dec 2010 07:28:16 +0530
Message-ID: <AANLkTikX5RL2S==gA2buWDGX+QkZfTOcjq2NWXGe3hFi@mail.gmail.com>
From: Jack Kohn <kohn.jack@gmail.com>
To: "Bhatia, Manav (Manav)" <manav.bhatia@alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: bixiaoyu <bixiaoyu@huawei.com>, "tictoc@ietf.org" <tictoc@ietf.org>
Subject: Re: [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: Sun, 05 Dec 2010 01:56:57 -0000

Your description appears to be correct.

Jack

On Sat, Dec 4, 2010 at 7:50 AM, Bhatia, Manav (Manav)
<manav.bhatia@alcatel-lucent.com> wrote:
> 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
>
>
> _______________________________________________
> TICTOC mailing list
> TICTOC@ietf.org
> https://www.ietf.org/mailman/listinfo/tictoc
>