Subject: Re: [ietf-privacy] [Int-area] Privacy concerns related to injecting a HOST_ID by a Provider NAT

From: <[email-masked]>
Date: Mon, 12 Sep 2011 17:18:37 +0200

Dear JFC,

Thank you for your feedback.

This is indeed another perspective. But, I'm not sure whether this usage should be elaborated in this I-D (we maintain the scope of RFC6269 and also we assume the HOST_ID proposal is transparent for end hosts. Only the address sharing function may inject a HOST_ID).

For the privacy discussion we documented in draft-boucadair, we adopted a simple approach which consists to compare the situation of an address sharing function inject a HOST_ID vs. no address sharing in the path.

Cheers,
Med

________________________________
De : JFC Morfin [mailto:[email-masked]]
Envoyé : lundi 12 septembre 2011 15:27
À : BOUCADAIR Mohamed OLNC/NAD/TIP; [email-masked]
Cc : [email-masked]
Objet : Re: [Int-area] Privacy concerns related to injecting a HOST_ID by a Provider NAT

At 16:33 09/09/2011, [email-masked] wrote:
That document discusses also the implications of the HOST_ID on privacy: http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04#section-1.2
As suggested in the INTAREA ML, I solicit this mailing list for a feedback on this point, particularly on the conclusions of the Privacy section.

I am considering this together with NBS, from a Internet/IETF user point of view.

IMHO the section on privacy is misconstrued as being in the wrong way. The initial idea might have been to use an HTTP.1.1. like solution to extend an IPv4 HOST identification that IPv6 will provide otherwise. However, this is not the main issue anymore.

On an internet use point of view, your HOST_ID actually is an HOST_HIDER.

It uncouples the cession from a unique IP address that can be identified and known outside of the local system. This means that the user can use it as a true CESSION_ID and move it around without the other end and the ISP knowing it and knowing what this CESSION-ID is. It can be associated to one or several ports, and NBSes. It can even be assigned to a whole user/host relation with a CESSION/RELATION_ID being encrypted with a time related key for example, and be used independently from the HOST_IP, i.e. from host to host, place to place, people to people, cloud to cloud in using an IP(/port) based encryption key, etc.

This actually seem to be the most powerful way to protect privacy.

As a consequence, IMHO, the problem is not to explain why the proposition does not harm privacy, but to minimize its privacy protection capabilities to not over worry IPrights protectors. You can also document the relational stability it permits.

Mohamed, thank-you for your contribution to the intelligent privacy and network neutrality protection cause!
jfc