Re: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06
Vijay Devarapalli <vijay.devarapalli@azairenet.com> Wed, 07 November 2007 00:06 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 1IpYRe-0002cK-Co; Tue, 06 Nov 2007 19:06:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpYRd-0002cA-6P for mobopts@irtf.org; Tue, 06 Nov 2007 19:06:57 -0500
Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpYRa-00062R-J9 for mobopts@irtf.org; Tue, 06 Nov 2007 19:06:57 -0500
Received: from [127.0.0.1] ([207.47.15.7]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 16:06:44 -0800
Message-ID: <4731017E.7020602@azairenet.com>
Date: Tue, 06 Nov 2007 16:06:22 -0800
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Rajeev Koodli <rajeev.koodli@nokia.com>
Subject: Re: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06
References: <C3563063.1D18B%rajeev.koodli@nokia.com>
In-Reply-To: <C3563063.1D18B%rajeev.koodli@nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 07 Nov 2007 00:06:44.0971 (UTC) FILETIME=[15202BB0:01C820D2]
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: Fan Zhao <fanzhao@marvell.com>, mobopts@irtf.org
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
Rajeev Koodli wrote: > 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. Ok, but I am questioning the need for changing the pseudo home address every time the return routability signaling is done (every 420 seconds). >>> 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. Ok, got it. You would need add this new destination option to the IANA considerations section. It is empty currently. >>> 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. How is the information about the encryption algorithm conveyed? >> 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? More fundamental than that. Why would the mobile node want to use a pseudo home address with its home agent? Vijay > > Thanks for the review. > > -Rajeev _______________________________________________ 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