Re: [ietf-privacy] NAT Reveal / Host Identifiers

<> Thu, 05 June 2014 13:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9E6D61A008D; Thu, 5 Jun 2014 06:12:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xl09Ux9Ze_Tb; Thu, 5 Jun 2014 06:11:57 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 30C911A008C; Thu, 5 Jun 2014 06:11:57 -0700 (PDT)
Received: from (unknown [xx.xx.xx.201]) by (ESMTP service) with ESMTP id 676F519039C; Thu, 5 Jun 2014 15:11:49 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 4816A384061; Thu, 5 Jun 2014 15:11:49 +0200 (CEST)
Received: from OPEXCLILM23.corporate.adroot.infra.ftgroup ([]) by OPEXCLILH03.corporate.adroot.infra.ftgroup ([]) with mapi id 14.03.0181.006; Thu, 5 Jun 2014 15:11:49 +0200
From: <>
To: Stephen Farrell <>, Hannes Tschofenig <>, "" <>
Thread-Topic: [ietf-privacy] NAT Reveal / Host Identifiers
Thread-Index: AQHPgLx0d+zesvLV90CTjyqp9hszQZtiegWw
Date: Thu, 5 Jun 2014 13:11:48 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B9330013CAF@OPEXCLILM23.corporate.adroot.infra.ftgroup>
References: <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2014.6.5.35719
Cc: "" <>, "Zuniga, Juan Carlos" <>
Subject: Re: [ietf-privacy] NAT Reveal / Host Identifiers
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jun 2014 13:12:04 -0000

Hi Stephen,

You referred in your message to an old version. The latest version of the document does not include any requirement, it is only an inventory of use cases when problems are encountered. The latest version is available at:

Some of these use cases are restricted to a single administrative domain while others span multiple domain. Privacy concerns are really important; these are discussed in RFC6967.

The use cases are not theoretical ones, but are those where complications arise. Explicitly calling out security risks (including privacy ones) will benefit to this work. It is really helpful to understand the use cases and call out any potential risks rather than speculating without actual understanding of what the problem is.

This document is the opportunity to record security and privacy concerns that apply to these use cases. The content of the document is not frozen. Adopting it as a WG document will undoubtedly enrich it and benefit from other perspectives that those of the authors. 


>-----Message d'origine-----
>De : ietf-privacy [] De la part de
>Stephen Farrell
>Envoyé : jeudi 5 juin 2014 14:48
>À : Hannes Tschofenig;
>Cc :; Zuniga, Juan Carlos
>Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers
>Hash: SHA1
>On 05/06/14 08:05, Hannes Tschofenig wrote:
>> If you want to review a document with privacy implications then
>> have a look at the NAT reveal / host identifier work (with
>> draft-boucadair-intarea-host-identifier-scenarios-04 currently in
>> a call for adoption).
>> I had raised my concerns several times now on the mailing list and
>> during the meetings.
>I share those concerns. And adopting this without any consideration
>of BCP188 would fly in the face of a very recent, very thoroughly
>discussed, IETF consensus. For something like this, the onus ought
>IMO be on the proposers to have done that work before asking for
>adoption. Based on the draft, they clearly have not done that.
>We could also ask to add more use-cases:
>use-case#12: spy on everyone more easily, TEMPORA++
>use-case#13: sell data that's even more fine-grained than clickstreams
>use-case#14: expose your n/w internals to help on path attackers
>use-case#15: track hosts from which people emit "dangerous" utterances
>use-case#16: block hosts from which people emit "dangerous" utterances
>use-case#17: charge me more for using two of my computers in my house
>The set of use-cases presented very much contradicts the explicit
>claim in the draft that no position is being taken as to the merits
>of this. IMO that argues strongly to not adopt this.
>One could also comment on the requirements that seem to
>require new laws of physics or are otherwise pretty odd:
>REQ#1: seems to require knowing from packets passing by that
>a device is a "trusted device" (and REQ#15 says that can be
>done with 16 bits;-) Hmm... are those qubits maybe?
>REQ#5: *all* IP packets MUST have a HOST_ID... but presumably
>without a flag day. Hmm...
>REQ#6: says this is a transport thing. Eh, why ask INT-AREA?
>REQ#10+REQ#11: MUST be intradomain only but MUST also be inter
>domain. Hmm...
>REQ#18: receiver MUST "enforce policies like QoS." Huh?
>Such a frankly bogus list of "requirements" also means that
>this is not something that ought be adopted in the IETF.
>I also think that this proposal has previously been proposed
>in other ways and not adopted. Such forum-shopping is yet
>another reason to not adopt it, and certainly not as an
>area wg thing without any broader IETF-wide consideration.
>(As an aside: having to play whack-a-mole with such repeat
>proposals is one of the downsides of area wgs. Not sure
>if anything can be done about that though.)
>In summary: ignoring BCP188, the selection-bias in use
>cases, the badly thought out "requirements" and forum
>shopping are all independently sufficient reasons to
>not adopt this. And of course that doesn't include all
>the other issues with potential solutions listed in
>RFC6967 (the reference to which is oddly to the I-D and
>not the RFC).
>My conclusion: this one ought go to /dev/null same as the
>previous attempts to shop the same thing into other parts
>of the IETF.
>> Ciao Hannes
>> -------- Original Message -------- Subject: 	[Int-area] Call for
>> adoption of draft-boucadair-intarea-host-identifier-scenarios-04
>> Date: 	Thu, 5 Jun 2014 04:20:56 +0000 From: 	Suresh Krishnan
>> <> To: 	Internet Area
>> <>
>> Hi all,
>> This draft was originally intended to be published as an AD
>> sponsored submission from the OPS area, but the authors have
>> expressed their interest to continue this work in the intarea wg
>> given that RFC6269 and RFC6967 originated here. The draft has been
>> updated to address the issues brought up during earlier
>> discussions on the wg mailing list and the latest version of the
>> draft is available at
>This call is being initiated to determine whether there is WG
>> consensus towards adoption of
>> draft-boucadair-intarea-host-identifier-scenarios-04 as an intarea
>> WG draft. Please state whether or not you're in favor of the
>> adoption by replying to this email. If you are not in favor, please
>> also state your objections in your response. This adoption call
>> will complete on 2014-06-19.
>> Regards
>> Suresh & Juan Carlos
>> _______________________________________________ ietf-privacy
>> mailing list
>Version: GnuPG v1
>ietf-privacy mailing list