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

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 05 June 2014 20:28 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ietf-privacy@ietfa.amsl.com
Delivered-To: ietf-privacy@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6A801A031C; Thu, 5 Jun 2014 13:28:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jY8rLdcoSfMF; Thu, 5 Jun 2014 13:28:41 -0700 (PDT)
Received: from mail-pb0-x234.google.com (mail-pb0-x234.google.com [IPv6:2607:f8b0:400e:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D6D1A02F2; Thu, 5 Jun 2014 13:28:41 -0700 (PDT)
Received: by mail-pb0-f52.google.com with SMTP id rr13so1600142pbb.11 for <multiple recipients>; Thu, 05 Jun 2014 13:28:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=P99WJQ2CNE477EK5hdcxMeesXkK81zynHkyRVi6FauI=; b=UHydhvpQgc4WHuDWdbb3spKihV+KPP8GyHZ4zydOFrZ7nh7gIpN8beVkjEld4yzMCg sjXBdaiIPXiIAM5HdJlC86oy234giCNyVGhC5mcgEVI+beN3CoO6VLMRw0hABLIcLpB0 in4qSlgL8+pnUuRVLln00knzkstBo/I2O2iXuQ2V9KePLc6HshiWZNitoHgPeTDawxVe hI8wBO3uZfiM3qX7JRmugmB8gIp4q0n+TEsBl/cxkOeYs0jad4HXFE83I5+6SW2sP1+3 Y5BU6H+yG/B3sMm4YkfIdNBbOBXL1x3g1SJIuiZZPsEP6yLjOdQ1E3V+PdxL8uVSVgVX D+Eg==
X-Received: by 10.69.10.164 with SMTP id eb4mr14280266pbd.35.1402000114875; Thu, 05 Jun 2014 13:28:34 -0700 (PDT)
Received: from [192.168.178.23] (13.199.69.111.dynamic.snap.net.nz. [111.69.199.13]) by mx.google.com with ESMTPSA id bc4sm26611797pbb.2.2014.06.05.13.28.31 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Jun 2014 13:28:34 -0700 (PDT)
Message-ID: <5390D2F8.6000801@gmail.com>
Date: Fri, 06 Jun 2014 08:28:40 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
References: <E87B771635882B4BA20096B589152EF628724B2C@eusaamb107.ericsson.se> <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie>
In-Reply-To: <53906711.5070406@cs.tcd.ie>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-privacy/0JhApKdlGgpxKZJsBB1YKbsQQuE
X-Mailman-Approved-At: Fri, 06 Jun 2014 08:11:55 -0700
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org>, int-area@ietf.org
Subject: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
X-BeenThere: ietf-privacy@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <ietf-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf-privacy/>
List-Post: <mailto:ietf-privacy@ietf.org>
List-Help: <mailto:ietf-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-privacy>, <mailto:ietf-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jun 2014 20:28:47 -0000

Stephen,

On 06/06/2014 00:48, Stephen Farrell wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> 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. 

I have to call you on that. WG adoption is not approval. It's agreement
to work on a topic. It is not OK to attempt a pocket veto on adoption
because you don't like the existing content.

> For something like this, the onus ought
> IMO be on the proposers to have done that work before asking for
> adoption. 

Why? Where do the rules say that?

As a matter of fact I tend to agree with many of your criticisms
of the draft, and I like the idea (below) of adding what we might
call the misuse cases. That's a discussion the intarea WG could have.

    Brian

> 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 
>> <suresh.krishnan@ericsson.com> To: 	Internet Area 
>> <int-area@ietf.org>
>>
>>
>>
>> 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 ietf-privacy@ietf.org 
>> https://www.ietf.org/mailman/listinfo/ietf-privacy
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJTkGcRAAoJEC88hzaAX42iFYYIAIlJHJE1BNetIdjhDTqlTfsX
> w+fFwSpCfi1LzZzxYR+ZgnL96ed8QPJ/YJEb4S1jZ0u2g1+DqMbSMsuQ6aW78+WM
> iHfyIqO8m7Ahkk1J++/5bK3N0fbqhMjWmqs1cCa7Gg/o9RScZQiMJQef8Iju5gVN
> 3dnd/7riV9THntV7DQdwGC0SXp9Wfwn2i3oAqxYVpEixCxxGbQBRPIiXBcaLBP4s
> lr86tLPCPdXB2K4uPsuofVxL/uGBkahF6DAGjq3URcUEVi/J82XL+eB/3bLQU5XG
> 2Mr0LMu7v4XQ+92zCjm7UmWmiL1fcQ+M0g+5nESSP8bO3sNlFlN33+jzsEGTBRM=
> =TF0g
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
> .
>