[Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06

Vijay Devarapalli <vijay.devarapalli@azairenet.com> Mon, 05 November 2007 22:28 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 1IpAQz-00032R-1m; Mon, 05 Nov 2007 17:28:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpAQx-000321-Nv for mobopts@irtf.org; Mon, 05 Nov 2007 17:28:39 -0500
Received: from mail2.azairenet.com ([207.47.15.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpAQw-0005kV-Bn for mobopts@irtf.org; Mon, 05 Nov 2007 17:28:39 -0500
Received: from [127.0.0.1] ([207.47.15.6]) by mail2.azairenet.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 14:28:36 -0800
Message-ID: <472F9911.2050105@azairenet.com>
Date: Mon, 05 Nov 2007 14:28:33 -0800
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: mobopts@irtf.org, QIU Ying <qiuying@i2r.a-star.edu.sg>, Fan Zhao <fanzhao@marvell.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 05 Nov 2007 22:28:36.0980 (UTC) FILETIME=[35324B40:01C81FFB]
X-Spam-Score: 0.8 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc:
Subject: [Mobopts] Review of draft-irtf-mobopts-location-privacy-solutions-06
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

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?

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))

>    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.

>    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 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?

>    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?

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.

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