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

[<[e-mail]>]

Re-,

I have two comments:

(1) 

If one missed the following sentences in -04 "Below is listed as set of requirements to be used to characterize
   each use case (discussed in Section 3):" and "Once this list is stabilized, each use case will be checked against
   these requirements.", then the requirements list can be seen as odd. I agree the wording is not so that clear. The initial intent was to identify the ones from the list that apply for each use case. That effort was abandoned in -05 to focus on the description of the use cases where problems are encountered.

(2)

Privacy concerns are not ignored. A section is present in the draft to recall some privacy-related issues: http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-scenarios-05#section-15. If there are other concerns not already covered, it will be relay helpful to explicit them. 

The document does not include any solution discussion but focuses only on the description of deployment use cases where problems are encountered. 

Cheers,
Med

>-----Message d'origine-----
>De : Stephen Farrell [mailto:[e-mail]]
>Envoyé : jeudi 5 juin 2014 15:24
>À : BOUCADAIR Mohamed IMT/OLN; Hannes Tschofenig; [e-mail]
>Cc : [e-mail]; Zuniga, Juan Carlos
>Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers
>
>
>Hi Med,
>
>On 05/06/14 14:11, [e-mail] wrote:
>> Hi Stephen,
>>
>> You referred in your message to an old version.
>
>That was the one for which the adoption call was issued. I
>guess just a typo.
>
>I looked quickly at the diff between 04 and 05 and my
>conclusion remains the same and most of my comment I think
>still apply, despite the removal of the odd requirements
>section.
>
>S.
>
>> 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:
>> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-
>scenarios-05.
>>
>>  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.
>>
>> Cheers, Med
>>
>>> -----Message d'origine----- De : ietf-privacy
>>> [mailto:[e-mail]] De la part de Stephen
>>> Farrell Envoyé : jeudi 5 juin 2014 14:48 À : Hannes Tschofenig;
>>> [e-mail] Cc : [e-mail]; Zuniga, Juan Carlos
>>> Objet : Re: [ietf-privacy] NAT Reveal / Host Identifiers
>>>
>>
>> Hiya,
>>
>> 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.
>>
>> S
>>
>>
>>>>>
>>>>> 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
>>>>> <[e-mail]> To: 	Internet Area
>>>>> <[e-mail]>
>>>>>
>>>>>
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>> http://tools.ietf.org/html/draft-boucadair-intarea-host-identifier-
>>
>>>>>
>scenarios-04
>>>>>
>>>>>
>>>>>
>> 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 [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/ietf-privacy
>>>>>
>>>
>>> _______________________________________________ ietf-privacy
>>> mailing list [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ietf-privacy
>>
>>