Re: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06
Rajeev Koodli <rajeev.koodli@nokia.com> Tue, 06 November 2007 22:53 UTC
Return-path: <mobopts-bounces@irtf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpXIs-0002YJ-S8; Tue, 06 Nov 2007 17:53:50 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpXIs-0002YD-4j for mobopts@irtf.org; Tue, 06 Nov 2007 17:53:50 -0500
Received: from smtp.nokia.com ([131.228.20.170] helo=mgw-ext11.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpXIq-0003QB-82 for mobopts@irtf.org; Tue, 06 Nov 2007 17:53:50 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id lA6MrI0d029476; Wed, 7 Nov 2007 00:53:26 +0200
Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Nov 2007 00:53:11 +0200
Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 16:53:07 -0600
Received: from 10.162.253.2 ([10.162.253.2]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Tue, 6 Nov 2007 22:53:07 +0000
User-Agent: Microsoft-Entourage/11.2.4.060510
Date: Tue, 06 Nov 2007 14:53:23 -0800
Subject: Re: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06
From: Rajeev Koodli <rajeev.koodli@nokia.com>
To: ext Vijay Devarapalli <vijay.devarapalli@azairenet.com>, mobopts@irtf.org, QIU Ying <qiuying@i2r.a-star.edu.sg>, Fan Zhao <fanzhao@marvell.com>
Message-ID: <C3563063.1D18B%rajeev.koodli@nokia.com>
Thread-Topic: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06
Thread-Index: Acggx9VYE+Y0RIy7EdyI8AAWy5YJpw==
In-Reply-To: <472F9911.2050105@azairenet.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 06 Nov 2007 22:53:07.0442 (UTC) FILETIME=[CC12BD20:01C820C7]
X-Nokia-AV: Clean
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Cc:
X-BeenThere: mobopts@irtf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Mobility Optimizations <mobopts.irtf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=unsubscribe>
List-Post: <mailto:mobopts@irtf.org>
List-Help: <mailto:mobopts-request@irtf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mobopts>, <mailto:mobopts-request@irtf.org?subject=subscribe>
Errors-To: mobopts-bounces@irtf.org
Hi Vijay, On 11/5/07 3:28 PM, "ext Vijay Devarapalli" <vijay.devarapalli@azairenet.com> wrote: > Hello, > > I reviewed the draft. It still needs a lot of work. > > Section 4.1 > ----------- > Section 4.1 is not making sense to me. The pseudo home address > changes every time return routability is run. It also changes > every time the CoA changes. Why does it have to change so often? > > Isn't one pseudo home address per session with a correspondent > node sufficient? > The pseudo HoA changing at each run of the RR provides some protection against profiling. Change of CoA upon handover, or a new CoA nonce index or a new RFC 3041 style CoA configuration makes a round of RR to be run. The pseudo HoA itself is not inducing new signaling, but a few computational steps. > Shouldn't the following be? > >> privacy keygen token = First (64, Kcn(Home Init Cookie | nonce | 2)) > > privacy keygen token = First (64, HMAC_SHA1(Kcn, (Home Init Cookie | > nonce | 2)) Yes. Noted. > >> When a correspondent node receives a Binding Update with a new >> destination option carrying the pseudo home address, it must first >> compute Kpm as above. > > You probably meant "a destination option carrying a new pseudo home > address". The home address destination option is always present in > the BU. > Actually, there is a new Type number for the Destination Option containing the pseudo HoA, so that the CN can first compute the String and recover the HoA. >> The computation is similar to how it would >> compute Kbm, except that the privacy keygen token is computed with >> the home address set to all zeros. > > Earlier in section 4.1, the computation of privacy keygen token is > shown as > > privacy keygen token = First (64, Kcn(Home Init Cookie | nonce | 2)) > > The home address is not used in this computation. So why is the home > address set to all zeros? > The text above (about HoA being set to zero) must be removed. It is still lingering around from the previous version. >> The correspondent node then >> stores the nonce indices, and Kbm itself. It may also send a normal >> Binding Acknowledgment to the mobile node. > > Wouldn't this defeat the purpose? The CN should include the pseudo > home address in the routing header in the binding ack. What does > "normal Binding Acknowledgment" mean? > "normal" means a regular Back, but you are right it should include the pseudo HoA. >> The privacy management key Kpm can be the same as the binding >> management key Kbm and the mobile node generates the pseudo home >> address as follows: >> >> pseudo home address = Enc(Kpm, home address) >> >> Where Enc(.) is a symmetric key encryption algorithm, for example, >> AES. > > hmm... You would need to pick *an* encryption algorithm and convey > the same to the CN. How would both ends pick the same algorithm > otherwise? Right. > > Section 5 > --------- > I am not sure why section 5 is needed at all. There is absolutely > no need to generate a pseudo home address with the home agent. The > MN can always use ESP in tunnel mode for MIPv6 signaling messages > and hide the home address from the access link. I suggest removing > sections 5.1, 5.2 and 5.3. > You mean in relation to Section 4, this offers no additional benefits? Thanks for the review. -Rajeev -- http://people.nokia.net/~rajeev > Section 5 also does not take into account scenarios where there > might not be a shared key between the MN and the HA. It also does > not account for scenarios where the home agent allocates a home > address for the mobile node as part of MIPv6 bootstrapping. > > I stopped reviewing here. :) > > Vijay > > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts
- [Mobopts] Review of draft-irtf-mobopts-location-p… Vijay Devarapalli
- Re: [Mobopts] Review of draft-irtf-mobopts-locati… Rajeev Koodli
- Re: [Mobopts] Review of draft-irtf-mobopts-locati… Vijay Devarapalli
- Re: [Mobopts] Review of draft-irtf-mobopts-locati… QIU Ying
- Re: [Mobopts] Review of draft-irtf-mobopts-locati… Rajeev Koodli