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

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 05 Nov 2007 14:28:33 -0800

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/mobopts

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 06 Nov 2007 14:53:23 -0800

Hi Vijay,

> I reviewed the draft. It still needs a lot of work.

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.

> privacy keygen token = First (64, HMAC_SHA1(Kcn, (Home Init Cookie |

Yes. Noted. 

> address". The home address destination option is always present in

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.

> address set to all zeros?

The text above (about HoA being set to zero) must be removed. It is still
lingering around from the previous version.

> "normal Binding Acknowledgment" mean?

"normal" means a regular Back, but you are right it should include the
pseudo HoA.

> the same to the CN. How would both ends pick the same algorithm

Right.

> sections 5.1, 5.2 and 5.3.

You mean in relation to Section 4, this offers no additional benefits?

Thanks for the review.

-Rajeev
-- 
http://people.nokia.net/~rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 06 Nov 2007 16:06:22 -0800

> pseudo HoA itself is not inducing new signaling, but a few computational

Ok, but I am questioning the need for changing the pseudo home
address every time the return routability signaling is done
(every 420 seconds).

> the pseudo HoA, so that the CN can first compute the String and recover the

Ok, got it. You would need add this new destination option to
the IANA considerations section. It is empty currently.

>> the same to the CN. How would both ends pick the same algorithm

How is the information about the encryption algorithm conveyed?

> 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

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 07 Nov 2007 09:54:28 -0800

> address every time the return routability signaling is done

Look at it this way: it does not cost signaling-wise; few computational
steps and provides protection against profiling. Probably more headache to
not compute pseudo HoA for this case alone..

> the IANA considerations section. It is empty currently.

Yes.

> How is the information about the encryption algorithm conveyed?

The default should be specified and assumed. There is no additional
signaling imagined for now.

> pseudo home address with its home agent?

Let's look at this in the other thread.

-Rajeev