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