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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 11 June 2014 15:09 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 041111A015F; Wed, 11 Jun 2014 08:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] 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 LfjyDMVRUijr; Wed, 11 Jun 2014 08:09:21 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id C8F091A00F0; Wed, 11 Jun 2014 08:09:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 196FCBE5D; Wed, 11 Jun 2014 16:09:20 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mawrMWL2097g; Wed, 11 Jun 2014 16:09:18 +0100 (IST)
Received: from [192.168.8.110] (217.64.246.66.mactelecom.net [217.64.246.66]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9C545BE56; Wed, 11 Jun 2014 16:09:18 +0100 (IST)
Message-ID: <5398711F.1020702@cs.tcd.ie>
Date: Wed, 11 Jun 2014 16:09:19 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>, Dan Wing <dwing@cisco.com>
References: <E87B771635882B4BA20096B589152EF628724B2C@eusaamb107.ericsson.se> <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu> <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com> <5393119F.6050805@cs.tcd.ie> <53986D94.5090801@isi.edu>
In-Reply-To: <53986D94.5090801@isi.edu>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-privacy/vHBxa30nJVscLdvSB4GnuTA0x80
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org>, Internet Area <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: Wed, 11 Jun 2014 15:09:29 -0000


On 11/06/14 15:54, Joe Touch wrote:
> 
> 
> On 6/7/2014 6:20 AM, Stephen Farrell wrote:
>> Yes, source addresses leak information that affects privacy. But
>> we do not have a practical way to mitigate that. So therefore
>> BCP188 does not call for doing stupid stuff, nor for new laws of
>> physics (unlike -04 of the draft we're discussing;-)
> 
> Again, BCP188 does not *call* for doing anything. There are no SHOULD-
> or MUST- level requirements in that doc. Let's please not wave it in the
> air as if there are.

I don't buy that argument at all and didn't wave anything anywhere.

BCP188 very clearly says:

   Pervasive monitoring is a technical attack that should be mitigated
   in the design of IETF protocols, where possible.

and

   Those developing IETF specifications need to be able to describe how
   they have considered PM, and, if the attack is relevant to the work
   to be published, be able to justify related design decisions.  This
   does not mean a new "pervasive monitoring considerations" section is
   needed in IETF documentation.  It means that, if asked, there needs
   to be a good answer to the question "Is pervasive monitoring relevant
   to this work and if so, how has it been considered?"

Reverting to RFC2119-keyword-lawyering is not IMO credible here.

S.



> 
> Joe
> 
>