IP Address Location Privacy and Mobile IPv6: Problem Statement
RFC 4882

Note: This ballot was opened for revision 06 and is now closed.

(Jari Arkko) Yes

(Ross Callon) No Objection

(Lars Eggert) No Objection

(Sam Hartman) (was Discuss) No Objection

Comment (2006-11-15)
No email
send info
I agree with Lisa that this document is unclear--not quite
to the point of earning a discuss for lack of clarity--but unclear
enough that if you haven't been reading mip6 documents for a while,
you won't understand what is going on.  It conflates profiling and
location privacy,  and describes more than supports its conclusions.

(Russ Housley) No Objection

Comment (2006-11-13 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  From the SecDir Review by Lakshminath Dondeti:
  > The security considerations section is pretty light.  It says in part 
  > that "solutions to provide location privacy ... must be secure 
  > ...."  Even though this is a problem statement document, perhaps it 
  > is the place to explain the security criteria used in evaluating 
  > candidate solutions.  For instance, the two types of solutions I can 
  > think of are 1) providing confidentiality of addresses by encrypting 
  > them and 2) making use of temporary addresses.  There are 
  > implications to using either type of solution.
  > Perhaps there are other ways to list the criteria too.

(Cullen Jennings) No Objection

Comment (2006-11-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
Ethereal has changed it's name. Might be better to just refer to these as a generic term like network sniffers.

(David Kessens) No Objection

(Dan Romascanu) No Objection

Comment (2006-11-14 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
'When the MN roams to another network, the location privacy problem
consists of two parts:  revealing information to its correspondents
and to on-lookers.'

I am wondering if this definition of the problem is not incomplete. I am missing any reference to the threat of exposure of the location information via management interfaces. The editors may consider adding some clarification text mentioning the fact that adequate protection means should be implemented to avoid the exposure of the location information obtained by authorized correspondents or visited networks ebtities via management interfaces or protocols.

(Mark Townsley) No Objection

Magnus Westerlund No Objection

(Ted Hardie) Abstain

(Lisa Dusseault) No Record

Comment (2006-11-15 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
This document lacks many important references and definitions for an outsider to be able to figure out what's going on.  
 - No reference for understanding where "Care of address" comes from -- this is most devastating as there is no reference or explanation to understand who gets the Care of address in the course of MIP6 operation
 - In poking around, I found that draft-haddad-alien-privacy-terminology-01.txt has a much better definition for "location privacy"
 - MN is not expanded on first use or defined, I have to assume MN=Mobile Node
 - HoA never defined -- is this same as HA which I assume is Home Address
 - CN never defined -- hunting through the informative reference to draft-haddad-momipriv-problem-statement-03.txt (also not helpfully named) I guess this is Correspondent Node?
 - ESP never defined
 - SIP never defined or referenced
 - Neither reference explains bidirectional tunneling, or reverse tunneling (are these the same???)
 - All these terms and acronyms seem to be very inconsistently used

Most fundamentally, the Conclusion -- that disclosing Care of address to a correspondent and disclosing Home address to an onlooker can compromise location privacy -- is not supported by this document or its references.  It's probably a reasonable statement if the WG has reviewed the document, but even if so, it's poorly explained and based on much material that's not here even in reference form.