Re: [Int-area] IPv4 address sharing abuse [was RE: draft-boucadair-intarea-nat-reveal-analysis]

[Jason Fesler <[e-mail]>]

Dan alerted me to this thread (Thanks).  Responding to what I see in the list archives.

First, I'd like to thank the contributors of draft-boucadair-intarea-nat-reveal-analysis, as well as RFC6269.

Today, we already have problems with the NATs deployed both at the enterprise level, as well as the prevalence of NAT in some countries.  Denying based on an IPv4/32 address is the last thing we want to do; it causes real harm.  However, there are times we must do so, to keep the service functional for others.

For us, having a HOST_ID represented in some fashion, is highly desirable.  This would be useful even if it was only partially persistent for a given subscriber.  if it had similar lifespans as DHCP or PPP, it would still be enough to single out a single bad actor distinctly from a pool of hundreds of other good actors, within a single IPv4/32 community.   

Lee Howard, you wrote:

> The stack or application on the other side of the connection would also
> have to be updated.  For instance, the web server.  Or the p2p client?

Should some form of nat revealing become standard, we would implement it.  If nothing standards-wise comes of this, then we would likely still pursue draft-wing-nat-reveal-option with strategic partner ISPs.  We are most troubled by TCP (HTTP, SMTP, POP, IMAP); we worry less about addressing the UDP aspects mentioned.

Modifying a few web apps and the kernel are NOT a barrier for us.  If any standard does come about, I'm certain that the apps used by the larger content operators will see updates to support those new standards.  

As to the legality of this in EU:  I'm not a lawyer.  That said, our support of nat revealing is not contingent on EU deployment.


-jason