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

Stephen Farrell <> Fri, 06 June 2014 15:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AA55E1A0085; Fri, 6 Jun 2014 08:59:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FoqXCNx7ojFY; Fri, 6 Jun 2014 08:59:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 53FFB1A007A; Fri, 6 Jun 2014 08:59:36 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63A5ABF79; Fri, 6 Jun 2014 16:59:29 +0100 (IST)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id y-ynNuFVaQnZ; Fri, 6 Jun 2014 16:59:29 +0100 (IST)
Received: from [] ( []) by (Postfix) with ESMTPSA id CE653BF7D; Fri, 6 Jun 2014 16:59:25 +0100 (IST)
Message-ID: <>
Date: Fri, 06 Jun 2014 16:59:26 +0100
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To:, Ted Lemon <>
References: <> <> <> <> <> <787AE7BB302AE849A7480A190F8B93300141B4@OPEXCLILM23.corporate.adroot.infra.ftgroup> <> <787AE7BB302AE849A7480A190F8B933001433C@OPEXCLILM23.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B933001433C@OPEXCLILM23.corporate.adroot.infra.ftgroup>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "" <>, "" <>, Brian E Carpenter <>
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: Fri, 06 Jun 2014 15:59:37 -0000

Hi Med,

On 06/06/14 12:41, wrote:
> [Med] I'm not sure about this Ted. There are other initiatives that
> try to solve the issue for particular use cases, see for instance
> this effort for HTTP:
> The
> rationale of the "host identifier scenarios" document is to group all
> use cases suffering from the same problem instead of focusing on one
> single case. This allows having a big picture view of the problem
> space.

I think XFF is actually a good example of why we ought not adopt
this work.

XFF is widely deployed already but somewhat flakey in terms of
interop so the authors of the above draft aimed to produce a spec
that just addressed interop. (*) That was adopted by an area WG
without (IMO) ever really considering the privacy implications,
and definitely without any effort having been made to develop a
more privacy-friendly mechanism (which could have been done, again
IMO) to solve what were the claimed use-cases. By the time it
got to the IESG that was in practice unfixable and after some
fairly painful discussions it ended up with 4 abstain ballots,
including mine. [1] (For those who quite reasonably don't need
to care about IESG balloting, an abstain means approximately

Of course that all also pre-dated BCP188 and the last year's
shenanigans so I'd hope we have learned to not keep doing that.

I'd be delighted if those who could get a better solution
implemented/deployed were to attempt to try to address the
privacy issues with XFF but it seems that at least in that
case relevant folks don't care (sufficiently;-) deeply about
our privacy to go do that.



(*) To be clear: I think the authors were genuinely just
trying to fix what they saw as an interop problem.