Subject: Re: [Mobopts] Re: [Mip6] [Fwd: FW: resubmit draft-irtf-mobopts-location-privacy-ps-00.txt with revised boilerplate]

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 3 Aug 2005 01:45:05 +0900

Hi Wassim

I just saw the Rajeev's presentation.

If a MN can randomly generate a sequence value that is larger than  
the previous value and
within sequence number window, it's hard to track the mobile node.  no?

I agree most of implementation today just increment one for sequence  
number.
Is there any description in RFC3775  saying that MN must increment  
sequentially for Seq number?

ryuji

On 2005/07/12, at 12:50, Wassim Haddad wrote:

> Hi Rajeev,
>
> Thanks for writing this draft.
>
> I just want to add that tracing the BU messages via the sequence  
> number
> can also reveal in real time to an eavesdropper the path taken by an
> unknown mobile node, i.e., by linking the BU messages and consequently
> the pseudo-IP addresses.
> However, the ability to follow the movements in real time, combined  
> with
> some prior infos about one particular target can lead to break the  
> user's
> anonymity.
>
> IMHO, it makes sense to add such scenario in the problem statement.
>
> We have addressed this particular issue in our "anonymity and  
> unlinkability
> solution for omipv6" (draft-haddad-privacy-omipv6-anonymity-00).
>
>
> Regards,
>
> Wassim H.
>
>
> On Mon, 11 Jul 2005, Rajeev Koodli wrote:
>
>
>>
>> Hello folks,
>>
>> I submitted the draft on Friday, I believe with the correct  
>> boilerplate
>> (see attached draft). I still got an error message.
>>
>> Anyway, please find the Location Privacy Problem Statement draft.
>>
>> Regards,
>>
>> -Rajeev
>>
>>
>>
>>> -----Original Message-----
>>>
>>
>>
>>> From:     Koodli Rajeev (Nokia-NRC/MtView)
>>> Sent:    Friday, July 08, 2005 7:42 PM
>>> To:    [email-masked]'
>>> Subject:    resubmit draft-irtf-mobopts-location-privacy- 
>>> ps-00.txt with revised boilerplate
>>>
>>>
>>> Here it is..
>>>
>>> Thanks,
>>>
>>> -Rajeev Koodli
>>>
>>>
>>>>  <<draft-irtf-mobopts-location-privacy-ps-00.txt>>
>>>>
>>>
>>> http://people.nokia.net/~rajeev
>>>
>>>
>>
>>
>>
>>
>
> _______________________________________________
> Mobopts mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mobopts
>
>

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

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 02 Aug 2005 10:30:23 -0700

> sequentially for Seq number?

I was looking for that. I could not find text that says the Sequence
Number must be incremented by one. The only requirement is that it is
greater than the previous one.

-Rajeev

>> I just want to add that tracing the BU messages via the sequence  number
>> However, the ability to follow the movements in real time, combined  with
>>> I submitted the draft on Friday, I believe with the correct  boilerplate
>>>> Subject:    resubmit draft-irtf-mobopts-location-privacy- ps-00.txt 
>>>> with revised boilerplate
>>>>
>>>>
>>>> Here it is..
>>>>
>>>> Thanks,
>>>>
>>>> -Rajeev Koodli
>>>>
>>>>
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6

---

From: Wassim Haddad <[email-masked]>
Date: Wed, 3 Aug 2005 10:01:16 +0300 (EEST)

Hi Ryuji,

On Wed, 3 Aug 2005, Ryuji Wakikawa wrote:

> the previous value and within sequence number window, it's hard to track
> the mobile node.  no?

=> IMHO, this may not be enough. The SQN should appear for an eavesdropper
as random and not larger than the previous one (i.e., this is still
traceable).
This issue has been addressed in:
draft-haddad-privacy-omipv6-anonymity-00

> sequentially for Seq number?

=> I think RFC3775 just mention that it should be larger.

Regards,

Wassim H.

> > IMHO, it makes sense to add such scenario in the problem statement.
Ã> >

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 03 Aug 2005 17:04:16 +0900

Hello Wassim

At Wed, 3 Aug 2005 10:01:16 +0300 (EEST),
> draft-haddad-privacy-omipv6-anonymity-00

Well, it's worth to look SQN trace, but we may solve this
by operations. 
MIP6 has the notion of window for SQN.  In some case, the SQN is
smaller than the previous one for eavesdropper, but still valid due to
SQN turnover (within SQN window).

> => I think RFC3775 just mention that it should be larger.

Ok

ryuji