Re: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-03

"Laganier, Julien" <julienl@qualcomm.com> Fri, 09 April 2010 22:51 UTC

Return-Path: <julienl@qualcomm.com>
X-Original-To: cga-ext@core3.amsl.com
Delivered-To: cga-ext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2E723A6A68 for <cga-ext@core3.amsl.com>; Fri, 9 Apr 2010 15:51:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.561
X-Spam-Level:
X-Spam-Status: No, score=-106.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 DZgwJg+-HwhD for <cga-ext@core3.amsl.com>; Fri, 9 Apr 2010 15:51:27 -0700 (PDT)
Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 1D8433A6A5E for <CGA-EXT@ietf.org>; Fri, 9 Apr 2010 15:51:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=julienl@qualcomm.com; q=dns/txt; s=qcdkim; t=1270853483; x=1302389483; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Laganier,=20Julien"=20<julienl@qualcomm.com> |To:=20Tony=20Cheneau=20<tony.cheneau@it-sudparis.eu>,=0D =0A=09"draft-ietf-csi-proxy-send@tools.ietf.org"=0D=0A=09 <draft-ietf-csi-proxy-send@tools.ietf.org>|CC:=20"CGA-EXT @ietf.org"=20<CGA-EXT@ietf.org>|Date:=20Fri,=209=20Apr=20 2010=2015:51:19=20-0700|Subject:=20RE:=20[CGA-EXT]=20Comm ents=20on=20draft-ietf-csi-proxy-send-03|Thread-Topic:=20 [CGA-EXT]=20Comments=20on=20draft-ietf-csi-proxy-send-03 |Thread-Index:=20AcrX8aQGya+YtVDLQo2KS5wPuemKpwAQ8PiA |Message-ID:=20<BF345F63074F8040B58C00A186FCA57F1C6AB47DA 4@NALASEXMB04.na.qualcomm.com>|References:=20<alpine.LNX. 2.00.1004091544180.9490@whitebox>|In-Reply-To:=20<alpine. LNX.2.00.1004091544180.9490@whitebox>|Accept-Language:=20 en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=a6e3GHXFQ/IHuL2L1xkyC98VmqIdSwg4UHMymr0o3lg=; b=steZR0zpP4EFPFaAUeHKRHZf+J6MwI/FUDecGRLpf7jrjJ1OED/fXJZz QRBZK92UZGyaqKO8f6R5AA4C23YpF2WwZy3N9ib6Y5FMk4WrhcfrZa61e vQ8OEQccFygMBSBafnlJB46txXSGa9FzAh6IWT34l2/ARSRpjeDhtTSec E=;
X-IronPort-AV: E=McAfee;i="5400,1158,5946"; a="38350679"
Received: from ironmsg01-l.qualcomm.com ([172.30.48.15]) by wolverine02.qualcomm.com with ESMTP; 09 Apr 2010 15:51:22 -0700
X-IronPort-AV: E=Sophos;i="4.52,179,1270450800"; d="scan'208";a="9195297"
Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironmsg01-l.qualcomm.com with ESMTP/TLS/RC4-MD5; 09 Apr 2010 15:51:22 -0700
Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.234.1; Fri, 9 Apr 2010 15:51:21 -0700
Received: from nalasexhub03.na.qualcomm.com (10.47.130.45) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.689.0; Fri, 9 Apr 2010 15:51:22 -0700
Received: from NALASEXMB04.na.qualcomm.com ([10.47.7.114]) by nalasexhub03.na.qualcomm.com ([10.47.130.45]) with mapi; Fri, 9 Apr 2010 15:51:21 -0700
From: "Laganier, Julien" <julienl@qualcomm.com>
To: Tony Cheneau <tony.cheneau@it-sudparis.eu>, "draft-ietf-csi-proxy-send@tools.ietf.org" <draft-ietf-csi-proxy-send@tools.ietf.org>
Date: Fri, 9 Apr 2010 15:51:19 -0700
Thread-Topic: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-03
Thread-Index: AcrX8aQGya+YtVDLQo2KS5wPuemKpwAQ8PiA
Message-ID: <BF345F63074F8040B58C00A186FCA57F1C6AB47DA4@NALASEXMB04.na.qualcomm.com>
References: <alpine.LNX.2.00.1004091544180.9490@whitebox>
In-Reply-To: <alpine.LNX.2.00.1004091544180.9490@whitebox>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "CGA-EXT@ietf.org" <CGA-EXT@ietf.org>
Subject: Re: [CGA-EXT] Comments on draft-ietf-csi-proxy-send-03
X-BeenThere: cga-ext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: CGA and SeND Extensions <cga-ext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cga-ext>
List-Post: <mailto:cga-ext@ietf.org>
List-Help: <mailto:cga-ext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cga-ext>, <mailto:cga-ext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Apr 2010 22:51:29 -0000

Tony,

Thanks for reviewing the draft. I'm following up on the timestamp issues you're pointing at below.

Tony Cheneau wrote:
> 
> [...] 
> 
> One technical comment/question:
> - Section 6.2
> "  When a MAG replies to a RS with a RA, the source address MUST be
>     equal to the MAG link-local address associated to the MN in this
>     PMIPv6 domain and its own link layer address as Source link-layer
>     address.  Then a timestamp (generated by the proxy) and nonce (if
>     appropriate, acccording to [RFC3971]), MUST be included.  Finally,
> a
>     PSO option signing the message MUST be included as the last option
> of
>     the message.  This procedure is followed for any other ND message
>     that could be generated by the MAG to a MN. "
> I understand from PMIP that the node that moves through the domain sees
> only one Link-Local address for all the MAGs. From your SNDP proposal,
> the node relies on the RFC 3971 rules to process the timestamp. I mean,
> the node could implement the mechanism proposed as a SHOULD in Section
> 5.3.4.2 of RFC 3971. Here, my concern is that the node will most likely
> consider the NDP messages of all the other MAG (after the first one it
> met) as replayed packets.
> 
> A small example, two MAGs, MAG_A and MAG_B. MAG_B's clock has minus one
> minute difference with MAG_A.  MAG_A sends a RA message secured with a
> PSO. The nodes verifies it and record a RDlast and TSlast value (as per
> RFC 3971). The node moves and MAG_B sends a RA message.  The node read
> the Timestamp option and compares it with its RDlast and TSlast value.
> The message is rejected as it looks like a replayed message.
> 
> Or maybe I missed the part that says the clocks are implicitly
> synchronised (or something else) ? Either way, could you clarify the
> situation for me and maybe add some text in the draft about this ?

PMIPv6 relies to a large extent on the use of Timestamps in Proxy Binding Updates. AFAIK there are no potential use of PMIPv6 that relies on sequence numbers for PBU re-ordering. When PMIPv6 use timestamps, the clocks on the MAGs have to be synchronized.

In addition, I am also unsure that there is a practical problem. The timestamp is only used for verifications of unsolicited messages. Since unsolicited router advertisements are only send periodically, it seems to me that they will not be sent often enough for the issue you describe to occur.

( and even my phone runs NTP today :)

--julien