Subject: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01)

From: Basavaraj Patil <[email-masked]>
Date: Fri, 02 Jun 2006 11:00:48 -0500

Hello,

This is the working group last call for I-D:
draft-ietf-mip6-location-privacy-ps-01.txt (IP Address Location
Privacy and Mobile IPv6: Problem Statement)

WG LC will end on June 16th, 06. Please review and send your comments
before the deadline.

The document is intended to be published as an Informational RFC.

-Chairs

The link for the I-D:
http://ietf.org/internet-drafts/draft-ietf-mip6-location-privacy-ps-01.txt

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

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 14 Jun 2006 20:04:48 +0200

Hi,

please find my comments below.

General
--------

- the term "roaming" is used in this draft many times, but is the term
(defined in RFC3753) really appropriate here? Shouldn't it be replaced
by "handover"? IMHO, the location privacy problem does also exist in
non-roaming cases (MN moves to different subnet within an operator's
network, i.e., intra-domain handover).

Comments on Section 2.1
------------

- The first sentence says

 "When a Mobile IP MN roams from its home network to a visited network,
   use of Care of Address in communication with a correspondent reveals
   that the MN has roamed." 

I think this is a bit vague. First, the problem does not only exist when
the MN roams from home to visited network, it also exists if it roams
from one visited to another visited network. Second, not only the fact
is revealed that the MN has roamed/moved, but also where the MN is
located after the movement. Suggested text:

 "When a Mobile IP MN does a handover from its home network to a visited
network *or from one visited network to another*, use of Care of Address
in communication with a correspondent reveals that the MN has just done
a handover *and where the MN is currently topologically located*." 

- location privacy is only compromised if the correspondent node is able
to link the HoA to a specific user/user identity. Although this may
often be the case, this should be explicitly stated (similar statement
exists in section 2.2).

- "to the correspondent node" should be added to the title of the
section (in section 2.2, the care-of address is disclosed as well, but
to on-lookers)

Comments on Section 2.2
------------

- Analog to the comment on section 2.1, the text should consider that
the problem does also exist when the MN moves from one visited network
to another. 

- analog to the comment on section 2.1, "to on-lookers" should be added
to the title

- It should be mentioned that location privacy is only compromised if
the on-looker is located on the path between MN and HA in bi-directional
tunneling mode or on the path between MN and CN in route optimization
mode. 

Comments on Section 3 and conclusion
------------------------

- The granularity of location information revealed from a care-of
address depends also on whether a local mobility management scheme such
as HMIPv6 or netlmm is used or not. Maybe this should be mentioned
somewhere.

- The draft concludes that two problems exist: disclosure of CoA to CN
and disclosure of HoA to on-lookers. I would like to see some conclusion
and discussions of requirements, so that solutions later can better be
evaluated against requirements. For instance
* which level of granularity regarding location privacy is required
(some argue that the level that netlmm provides is sufficient)? 
* it should be possible to combine solutions for hiding CoA from CN and
hiding HoA from on-lookers (i.e., provide both simultaneously) 
* Route optimization should certainly be supported in both cases so that
delay-sensitive services and efficient routing are possible.

- The following paragraph is not really clear to me: "With its
correspondents, the MN can either communicate directly or
   reverse tunnel its packets through the Home Agent.  Using reverse
tunneling does not reveal the new IP address of the MN, although
performance may vary depending on the particular scenario.  In some
instances, the performance difference could be noticeable enough to
serve as a hint to the correspondent." 

What exactly is this hint about and how reliable is such hint? Does it
mean that the correspondent can find out that the MN is not located at
home only based on packet delay? While it might be true in some cases
that the delay of reverse tunneled packets is high if the MN is away
from home, this is not generally true, since there are many potential
factors contributing to the packet delay. E.g., the delay heavily
depends on the access technology used. When a users changes from a GPRS
home network to a WLAN visited network, the packet delay may be much
higher if the MN is at home compared to when it is located in the
visited network. Since the correspondent node usually doesn't know which
access technology is used by the MN, I do not see how the CN can derive
the MN's location from packet delay.

- Kilian 

-----Original Message-----
From: Basavaraj Patil [mailto:[email-masked]] 
Sent: Freitag, 2. Juni 2006 18:01
To: [email-masked]
Subject: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01)

Hello,

This is the working group last call for I-D:
draft-ietf-mip6-location-privacy-ps-01.txt (IP Address Location Privacy
and Mobile IPv6: Problem Statement)

-Chairs

The link for the I-D:
http://ietf.org/internet-drafts/draft-ietf-mip6-location-privacy-ps-01.t
xt

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 15 Jun 2006 16:09:04 -0700

Hi Kilian,

thanks for the input.

>network, i.e., intra-domain handover).
we are not following the strict definition of "roaming" as in RFC3753. 
Roaming may or may not
have operator intervention. The draft is neutral about it. Handover is a 
special case of mobility in
which you are concerned about existing sessions. So, when a MN roams, it 
could have
existing sessions or not. If you would like me to define the term, I 
can. For instance,

Roaming: The process of moving from one network to another (with or 
without existing
sessions).

>Comments on Section 2.1
I agree with the first part. The second part is commonly understood, and 
is described in the
Introduction. Perhaps I could add to:

"Furthermore, a user may not wish to reveal roaming to correspondent(s). 
In Mobile IP, this
 translates to the use of Care of Address."

"As with Home Address, the Care of Address can also reveal the 
topological location of the
Mobile Node".

>often be the case, this should be explicitly stated (similar statement
This is again common for the entire document.

 From Section 1:

:..The location privacy problem is particularly applicable to Mobile IP 
where the Home Address on
 a visited network can reveal device roaming and, together with a user 
identifier (such as a SIP URI),
can reveal user roaming.."

>section (in section 2.2, the care-of address is disclosed as well, but
Okay.

>Comments on Section 2.2
Ok.

>- analog to the comment on section 2.1, "to on-lookers" should be added
Ok.

>tunneling mode or on the path between MN and CN in route optimization
Check.

>Comments on Section 3 and conclusion
Well, regardless of the on-link prefix, the granularity points to the 
physical address of the
ISP. With more sophisticated tools, one could get a better blueprint, 
which is recognized at the
end of 2nd paragraph of Section 3.

>(some argue that the level that netlmm provides is sufficient)? 
We should be able to hide HoA all together and have something to say 
about how to use CoA
judiciously if the MN is concerned about revealing the CoA.

>delay-sensitive services and efficient routing are possible.
None of these are excluded in the solutions. The only requirement I see 
is that the solutions
should not require additions to Mobile IP functional elements. So, you 
have a MN, HA and CN.
And you have MIP signaling protocol. What protocol enhancements we need 
to provide location
privacy? (I somehow think that this assumption of MIP model is clear in 
all the protocol work
surrounding MIP. I could make it clear that no new elements are required)

>the MN's location from packet delay.
It does not state that the CN can derive MN's location from packet 
delay. The hints are just
that; they are not conclusive. If you roam across continents, your CN 
may notice the difference.
That's all it is trying to say ("_In some instances_..). I could add 
"However, such a difference
is not always conclusive".

-Rajeev

---

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 19 Jun 2006 18:26:06 +0200

Hi Rajeev,

see comments inline

> From: Rajeev Koodli [mailto:[email-masked]] 
> Sent: Freitag, 16. Juni 2006 01:09
> To: Kilian Weniger
> Cc: [email-masked]
> Subject: Re: [Mip6] WG LC: draft-ietf-mip6-location-privacy-ps (01)
> 
> 
> Hi Kilian,
> 
> thanks for the input.
> 
> 
> Kilian Weniger wrote:
> 
> >General
> >--------
> >

I see.

> which you are concerned about existing sessions. So, when a 

Yes, but it seems to me that in the context of Mobile IPv6 the term "l3
handovers" is often used to describe the event that a MN moves to a new
subnet, i.e., even without having an active session (see, for instance,
RFC3775 section 11.5.1: "When the mobile node detects an L3 handover, it
performs Duplicate Address Detection": DAD should also be done if no
active session exists). But I agree, strictly speaking this is not
correct.

> MN roams, it 

I'm not in favour of using the term "roaming" in a different way than
defined in RFC3753, since I was quite confused about the usage of this
term in this draft. What do others think? 
If "l3 handover" is not appropriate, how about "l3 movement" (or
introducing a new term)?

> topological location of the

ok

> judiciously if the MN is concerned about revealing the CoA.

yes, but I think this requirement is not explicitly stated in the draft.
My proposal was to add some text that explicitly states requirements. 

> None of these are excluded in the solutions. The only 

I didn't say that they are excluded. I just proposed to explicitly state
requirements, since this may help in developing and evaluating
solutions.

> requirement I see 

ok (however, it might be difficult to check solutions against this
requirement, e.g., how much modifications to the entity "HA" are allowed
to still call it "HA"?)

> is not always conclusive".

ok, maybe with some additional text about why it is often not conclusive
(e.g., delay varies with access technologies used by MN; CN doesn't know
which technology is used by MN)

- Kilian

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 21 Jun 2006 17:39:55 -0400

Hi Kilian,

>If "l3 handover" is not appropriate, how about "l3 movement" (or
We are using the word in its literal sense. I for one was not thinking 
about 3753, and I propose
we move forward with the addition of above sentence to the draft. (It's 
kind of late for this discussion
at LC).

>My proposal was to add some text that explicitly states requirements. 
I would like it to be as flexible as possible, yet be within the 
existing MIP framework of
functional elements (i.e., MN, HA and CN).

>requirements, since this may help in developing and evaluating
See above.

>requirement, e.g., how much modifications to the entity "HA" are allowed
hmm.. I am inclined to thinking that protocol extensions are what we 
work on. If there are new functional
elements, that's outside the scope.

So, I propose adding the following:

"The solutions to the location privacy problem described in this 
document should be new protocols or
existing protocol enhancements within the current Mobile IPv6 framework 
involving the Mobile Node, the
Home Agent and the Correspondent Node."

Okay.

Thanks,

-Rajeev

>>>draft-ietf-mip6-location-privacy-ps-01.txt (IP Address 
>>>      
>>>
>>Location Privacy
>>    
>>
>>>http://ietf.org/internet-drafts/draft-ietf-mip6-location-priv
>>>      
>>>
>acy-ps-01.t
>  
>
>>>xt
>>>
>>>