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

Joe Touch <> Thu, 05 June 2014 20:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 86A2E1A0278; Thu, 5 Jun 2014 13:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lTybOCzNxueq; Thu, 5 Jun 2014 13:43:32 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4424F1A018E; Thu, 5 Jun 2014 13:43:32 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s55KgRuT023551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jun 2014 13:42:27 -0700 (PDT)
Message-ID: <>
Date: Thu, 05 Jun 2014 13:42:27 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Brian E Carpenter <>, Stephen Farrell <>
References: <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-Mailman-Approved-At: Fri, 06 Jun 2014 08:11:56 -0700
Cc: "" <>,
Subject: Re: [ietf-privacy] [Int-area] NAT Reveal / Host Identifiers
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Privacy Discussion List <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Jun 2014 20:43:33 -0000

On 6/5/2014 1:28 PM, Brian E Carpenter wrote:
> 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

I'd vote for WG adoption, and agree with the above with the caveat that 
such "misuse" should focus on:

a) ways proposed mechanisms "undo" current mechanisms that *might* have 
been intended to preserve privacy (e.g., NATs are deployed for lots of 
reasons, and we never know intent per se, but privacy preservation CAN 
be a reason)

b) ways proposed mechanisms can exceed restoring what such devices 
"undo" and be used to track hosts, processes, or other identities beyond 
what the original packet *would have already exposed*.

I.e., for a device that inserts the source IP address and TCP source 
port for NAT traversal, it would at best be considered to 'undo' the 
potential privacy-creation intent of a NAT, but would NOT be considered 
to exceed what the original packet conveyed.