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

From: <[email-masked]>
Date: Fri, 9 Sep 2011 16:33:54 +0200

Dear all,

We have edited a document to discuss a set of solutions to mitigate some abuse issues identified in RFC6269. This document is available at:
http://tools.ietf.org/html/draft-boucadair-intarea-nat-reveal-analysis-04

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.

Many thanks in advance.

Cheers,
Med

---

From: JFC Morfin <[email-masked]>
Date: Mon, 12 Sep 2011 15:27:00 +0200

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>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

---

From: <[email-masked]>
Date: Mon, 12 Sep 2011 17:14:03 +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

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.

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.

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

---

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

Dear JFC,

Cheers,
Med

---

From: JFC Morfin <[email-masked]>
Date: Mon, 12 Sep 2011 19:15:12 +0200

At 17:18 12/09/2011, [email-masked] wrote:
>Only the address sharing function may inject a HOST_ID).

That can be at random, along an algorithm, parameters etc. and user 
request/decision (you cannot decide who is running that function as 
long as an IP address is associated to it). Anyway, this is the way I 
will probably implement it in my IUI prototype support.
Best
jfc