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

["QIU Ying" <[e-mail]>]

Hi, Vijay

Thanks for your reviewing this draft. As per your 5 comments on section 5, 
below is my reply.


1. I am not sure why section 5 is needed at all.

R:  The target of the solution in section 4 is to hide MN's HoA from 
eavesdroppers. The solution uses the original RR procedure. So the CN could 
always bind the real HoA and CoA. It implies that CN can always track the MN 
movement.  Moreover an eavesdropper on path HA-CN can know at least that the 
MN is outside of home network by capturing the HoTI message.

Contrastively, the solution in section 5 tries to hide its real HoA from 
everyone, even from the CN.

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

R:  The pseudo home address is not generated for the home agent. It ensures 
that the RR procedure can be processed as usual and that not reveal real 
HoA.

3. Section 5 also does not take into account scenarios where there might not 
be a shared key between the MN and the HA.

R: All of our proposals are focused on IP layer. In this case, all of the 
session keys have been established and shared already. The process of 
establishing the session keys on the upper layer, such as IKE, which is 
beyond our scope.

4. It also does not account for scenarios where the home agent allocates a 
home address for the mobile node as part of MIPv6 bootstrapping.

R: Again, the purpose of these solutions is to protect the location privacy 
in IP layer. No matter how to allocate the home addresses, either stateful 
or stateless, the roles of home address in IP layer are the same - to 
identify the mobile nodes.  Therefore, how to allocate home address does not 
affect the solution.

5.  I suggest removing sections 5.1, 5.2 and 5.3.

R: As above reasons, the answer is definitely NO :-)


Regards and Thanks
Qiu Ying



----- Original Message ----- 
From: "Rajeev Koodli" <[e-mail]>
To: "QIU Ying" <[e-mail]>; "Fan Zhao" <[e-mail]>
Sent: Wednesday, November 07, 2007 6:54 AM
Subject: FW: [Mobopts] Review of 
draft-irtf-mobopts-location-privacy-solutions-06


>
> Qiu Ying and Fan,
>
> I hope you can answer Vijay's questions about Section 5.
>
> Thanks,
>
> -Rajeev
> -- 
> http://people.nokia.net/~rajeev
>
>
>
> ------ Forwarded Message
> From: ext Vijay Devarapalli <[e-mail]>
> Date: Mon, 05 Nov 2007 14:28:33 -0800
> To: <[e-mail]>, QIU Ying <[e-mail]>, Fan Zhao
> <[e-mail]>
> Subject: [Mobopts] Review of
> draft-irtf-mobopts-location-privacy-solutions-06
>
> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mobopts
>
> ------ End of Forwarded Message
> 


------------ Institute For Infocomm Research - Disclaimer -------------This email is confidential and may be privileged.  If you are not the intended recipient, please delete it and notify us immediately. Please do not copy or use it for any purpose, or disclose its contents to any other person. Thank you.--------------------------------------------------------

_______________________________________________
Mobopts mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mobopts