Re: [P2PSIP] time synchronization?

"Songhaibin (A)" <haibin.song@huawei.com> Wed, 28 August 2013 01:22 UTC

Return-Path: <haibin.song@huawei.com>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0013F21E80E9 for <p2psip@ietfa.amsl.com>; Tue, 27 Aug 2013 18:22:27 -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=[AWL=0.000, 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 rkWs94ydqY+S for <p2psip@ietfa.amsl.com>; Tue, 27 Aug 2013 18:22:22 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C57311E834B for <p2psip@ietf.org>; Tue, 27 Aug 2013 18:22:20 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AWQ63946; Wed, 28 Aug 2013 01:22:18 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 28 Aug 2013 02:21:31 +0100
Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 28 Aug 2013 02:22:16 +0100
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.96]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Wed, 28 Aug 2013 09:22:11 +0800
From: "Songhaibin (A)" <haibin.song@huawei.com>
To: Roland Bless <roland.bless@kit.edu>
Thread-Topic: [P2PSIP] time synchronization?
Thread-Index: AQHOowoSSaWNMjiLU0qWc5UIwQI8Rpmp0nsg
Date: Wed, 28 Aug 2013 01:22:10 +0000
Message-ID: <E33E01DFD5BEA24B9F3F18671078951F2478AB1E@nkgeml501-mbs.china.huawei.com>
References: <E33E01DFD5BEA24B9F3F18671078951F24743A9D@nkgeml501-mbs.china.huawei.com> <521C74F1.5000903@kit.edu>
In-Reply-To: <521C74F1.5000903@kit.edu>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.66]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "p2psip@ietf.org" <p2psip@ietf.org>
Subject: Re: [P2PSIP] time synchronization?
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Aug 2013 01:22:30 -0000

Hi Roland,

Thanks for your point.

In -base document, the last paragraph of section 13.6.3 mentions a little about time synchronization for preventing replay attack.

By the way, I guess time synchronization can be overlay specific. So the overlay configuration file can include some parameters to say whether there is synchronization or not. For the overlays which do not enforce it, overlay nodes can just ignore the related fields.

BR,
-Haibin

-----Original Message-----
From: Roland Bless [mailto:roland.bless@kit.edu] 
Sent: Tuesday, August 27, 2013 5:44 PM
To: Songhaibin (A)
Cc: p2psip@ietf.org
Subject: Re: [P2PSIP] time synchronization?

Hi,

On 14.08.2013 03:31, Songhaibin (A) wrote:
> In -diagnostics draft, we have timestamp that is used by the
> intermediate nodes to check if the message is expired or not. It raises
> a problem of time synchronization. I think we need a decision from the
> WG. We need careful consideration on how to use the timestamp because
> time synchronization is a barrier in open Internet environment, while in
> a managed environment, it may be less of a problem. Do we want to
> enforce the time synchronization or do we want to lose the feature to
> check the message expiration (and one-way-delay)? Please tell what you
> are thinking about.

As the base (RELOAD) draft doesn't require any time synchronization
mechanism, I think, it's not useful to enforce the use of
time synchronization in any other draft. IMHO it's obvious
that you may have advantages if time synch is available;
more important is how you could distinguish from the protocol
if it's used or not.

Regards,
 Roland