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