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

[Eliot Lear <[e-mail]>]

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.

Eliot