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

Eliot Lear <> Mon, 09 June 2014 16:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 849951A0264; Mon, 9 Jun 2014 09:32:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.151
X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KrqSeXJ75Zi4; Mon, 9 Jun 2014 09:32:24 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 815EF1A0257; Mon, 9 Jun 2014 09:32:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=4540; q=dns/txt; s=iport; t=1402331543; x=1403541143; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Y0e/Y6IB7c4ye31/W0rroDAI3/MGYnsh6880j/bFqlI=; b=amtZoZYqsdqx7xpmp/gMP7IC7BXTg6tcR7R5we7hBBTO5yvLrHDqORlG +7ZFV47O25JfkW1pgDbtmbCR9ipKyME1erTXA3k9e1tc77JW1Zy69kEu8 WmIupS29OgiNoOFu8wCdYf0ZeVDnJ/qjsXhzWhr9cfjrzBUELI3+FYZHn M=;
X-IronPort-AV: E=Sophos;i="4.98,1003,1392163200"; d="scan'208,217";a="79655676"
Received: from (HELO ([]) by with ESMTP; 09 Jun 2014 16:32:22 +0000
Received: from ELEAR-M-C3ZS.CISCO.COM ([]) by (8.14.5/8.14.5) with ESMTP id s59GWLX3023173; Mon, 9 Jun 2014 16:32:21 GMT
Message-ID: <>
Date: Mon, 09 Jun 2014 18:32:21 +0200
From: Eliot Lear <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Stephen Farrell <>, Dan Wing <>
References: <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: multipart/alternative; boundary="------------060505040501030907000309"
Cc: "" <>, Internet Area <>, Joe Touch <>
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: Mon, 09 Jun 2014 16:32:25 -0000

Hi Stephen,

On 6/7/14, 3:20 PM, Stephen Farrell wrote:

> 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.

This came up today in a discussion around spam and cybersecurity with at
least one major service provider who has some pretty sophisticated
cbyersecurity systems.  Someone mentioned CGN and how entire groups of
customers are blocked when a single IP address goes bad.  We even
experienced this on the IAB, by the way, when its MSP got blocked by an
anti-spam site due to presumably someone else misusing them.  Our
architecture isn't really set up for IP address sharing or hiding.  If
your source address is naughty, the only back pressure I have at my
disposal is to block it.  If enough in an address range are bad, I might
block a range, even if that means some small amount of good mail being
blocked.  Go to a lousy SP and this is what it gets you.

But does adding a header solve the problem?  Not unless it is signed AND
I believe the signature.  And then I had better be willing to spend the
processing time to sort out your good customers from your bad
customers.  I *might* do that if you're at a very big mail service
provider, in which case I probably get very little spam, anyway.  I
probably won't do that if you're Joe's small time ISP, unless there is
some scaling feature not yet deployed today.