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

Dan Wing <dwing@cisco.com> Sat, 07 June 2014 01:38 UTC

Return-Path: <dwing@cisco.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 E99361A027C; Fri, 6 Jun 2014 18:38:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.152
X-Spam-Level:
X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 b8uXY1yE22ab; Fri, 6 Jun 2014 18:38:33 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BD31A0268; Fri, 6 Jun 2014 18:38:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1822; q=dns/txt; s=iport; t=1402105107; x=1403314707; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HMfCjiiTZSrhIrc+g0B1+APPCAABuUhKn0p7rSjUT2g=; b=P8QR/5dfMFkowsMmXR21VX2VAJjf+jFBHS1JKGMhlS3rQ+GSC91KjgNd 5ZrSMfVGE0RJWxQIbMu+kUFJC7iS94HQfRFI3a+84uf2Vai48WXFk1Npb diFsIvPFxNcuywnrDGC2L7+8ySGxWzx1PU7QGgzNQO+8ZttBTH2EM3LVJ E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAJJsklOtJV2d/2dsb2JhbABZgw3FNgGBBRZ1hAMBAQEDATo/BQsLEgYuSQ4GExSIJgjNSheONjMHgyuBFgEDijGPbIZ2jE6DXB0
X-IronPort-AV: E=Sophos;i="4.98,992,1392163200"; d="scan'208";a="51017724"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 07 Jun 2014 01:38:26 +0000
Received: from [10.21.72.236] ([10.21.72.236]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s571cP0Y005132; Sat, 7 Jun 2014 01:38:25 GMT
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <5390CEC9.3000005@isi.edu>
Date: Fri, 6 Jun 2014 18:38:25 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <5D2CC7D6-D9E1-49A8-818C-5FB33DC283C0@cisco.com>
References: <E87B771635882B4BA20096B589152EF628724B2C@eusaamb107.ericsson.se> <539016BE.3070008@gmx.net> <53906711.5070406@cs.tcd.ie> <5390CEC9.3000005@isi.edu>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf-privacy/-tymxqvYx9gtdTl9bPXTGmNvNq0
X-Mailman-Approved-At: Mon, 09 Jun 2014 07:02:38 -0700
Cc: "ietf-privacy@ietf.org" <ietf-privacy@ietf.org>, Internet Area <int-area@ietf.org>, Joe Touch <touch@isi.edu>
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: Sat, 07 Jun 2014 01:38:35 -0000

On Jun 5, 2014, at 1:10 PM, Joe Touch <touch@isi.edu> wrote:

> On 6/5/2014 5:48 AM, Stephen Farrell wrote:
>> 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.
> 
> That BCP thankfully includes zero RFC2119 language except the single word "should" (not capitalized) in the abstract, thus every new document is trivially compliant with its recommendations.
> 
> (I really wish the IETF community cared as much about technical correctness and protocol robustness as they did about issuing that IMO largely political statement, which "flies in the face" of 40+ years of using globally-assigned, globally-unique IP addresses as endpoint identifiers as the basis of the Internet architecture).

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.

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.

-d