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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Sat, 07 June 2014 13:20 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E912A1A035C; Sat, 7 Jun 2014 06:20:43 -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 tzpM-MpRaGJe; Sat, 7 Jun 2014 06:20:41 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8EA1A035D; Sat, 7 Jun 2014 06:20:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 20D19BF50; Sat, 7 Jun 2014 14:20:33 +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 UpY5tvbqAAG2; Sat, 7 Jun 2014 14:20:32 +0100 (IST)
Received: from [10.87.48.12] (unknown [86.42.16.21]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DD549BF4D; Sat, 7 Jun 2014 14:20:31 +0100 (IST)
Message-ID: <5393119F.6050805@cs.tcd.ie>
Date: Sat, 07 Jun 2014 14:20:31 +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: 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>
In-Reply-To: <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com>
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/int-area/KHa4sAoaF4Q-wQhBimHIutdi90w
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org>, Internet Area <int-area@ietf.org>
Subject: Re: [Int-area] [ietf-privacy] NAT Reveal / Host Identifiers
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 07 Jun 2014 13:20:44 -0000

Hi Dan,

On 07/06/14 02:38, Dan Wing wrote:
> 
> Stephen,
> 
> It seems NAPT has become IETF's privacy feature of 2014 because
> multiple users are sharing one identifier (IP address and presumably
> randomized ports [RFC6056], although many NAPT deployments use
> address ranges because of fear of compressing log files).  As a
> former co-chair of BEHAVE it is refreshing to see the IETF embracing
> NAPT as a desirable feature.

Embracing seems like significant overstatement to me, but maybe
that's understandable given how calmly NAT is generally debated.

NATs have both good and bad properties. The slightly better privacy
is one of the good ones.

Recognising that reality is neither embracing nor refreshing IMO,
nor does it mean NAPT is (un)desirable overall. (That's an argument
I only ever watch from the side-lines thanks:-)

> However, if NAPT provides privacy and NAT Reveal removes it, where
> does that leave a host's IPv6 source address with respect to BCP188?
>
> Afterall, an IPv6 address is quite traceable, even with IPv6 privacy
> addresses (especially as IPv6 privacy addresses are currently
> deployed which only obtain a new IPv6 privacy address every 24 hours
> or when attaching to a new network).  If BCP188 does not prevent
> deployment of IPv6, I would like to understand the additional privacy
> leakage of IPv4+NAT+NAT_Reveal compared to the privacy leakage of
> IPv6+privacy_address.

I'm frankly amazed that that's not crystal clear to anyone who
has read all 2.5 non-boilerplate pages of the BCP. Or even just
the last two words of the 1-line abstract (hint: those say "where
possible.")

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

Adding new identifiers with privacy impact, as proposed here, is
quite different.

S.

PS: If someone wants to propose what they think is a practical
way to mitigate the privacy issues with source addresses, please
write a draft first and then start a separate thread somewhere.


> 
> -d
>