netdev - Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1322611509.2684.52.camel@bwh-desktop>
Date:	Wed, 30 Nov 2011 00:05:09 +0000
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Krzysztof Olędzki <ole@....pl>
CC:	Jan Engelhardt <jengelh@...ozas.de>,
	Ulrich Weber <ulrich.weber@...hos.com>,
	Amos Jeffries <squid3@...enet.co.nz>,
	"sclark46@...thlink.net" <sclark46@...thlink.net>,
	"kaber@...sh.net" <kaber@...sh.net>,
	"netfilter-devel@...r.kernel.org" <netfilter-devel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [RFC PATCH 00/18] netfilter: IPv6 NAT

On Tue, 2011-11-29 at 22:38 +0100, Krzysztof Olędzki wrote:
> On 2011-11-29 13:23, Jan Engelhardt wrote:
> >
> > On Tuesday 2011-11-29 10:19, Ulrich Weber wrote:
> >> On 28.11.2011 23:03, Amos Jeffries wrote:
> >>> I'm going to dare to call FUD on those statements...
> >>>    * Load Balancing - what is preventing your routing rules or packet
> >>>   marking using the same criteria as the NAT changer? nothing. Load
> >>>   balancing works perfectly fine without NAT.
> >
> > Source address selection, having to occur on the source, would
> > require that the source has to know all the parameters that a {what
> > would have been your NAT GW} would need to know, which means you have
> > to (a) collect and/or (b) distribute this information. Given two
> > uplinks that only allow a certain source network address (different
> > for each uplink), combined with the desire to balance on utilization,
> > (a) a client is not in the position to easily obtain this data unless
> > it is the router for all participants itself, (b) the clients needs
> > to cooperate, and one cannot always trust client devices, or hope for
> > their technical cooperation (firewalled themselves off).
> >
> > Yes, NAT is evil, but if you actually think about it, policies are
> > best applied where [the policy] originates from. After all, we also
> > don't do LSRR, instead, routers do the routing, because they just
> > know much better.
> >
> >> I fully agree. NAT can not replace your firewall rules.
> >>
> >> However with NAT you could get some kind of anonymity.
> >
> > Same network prefix, some cookies, or a login form. Blam, identified,
> > or at least (Almost-)Uniquely Identified Visitor tagging.
> 
> But without NAT you have pretty big chance to have the same IPv6 
> *suffix* everywhere, based on you MAC address. In your Home, your Work, 
> in a Cafe or in a hotel during your vacations in Portugal. So yes, NAT 
> is not a perfect solution but it really helps you privacy.

If you enable NAT on your own network, how does this help when you use
all those other networks that may not use NAT or may have a predictable
mapping from MAC address to public IPv6 address?

Instead you need to deal with this on the mobile device itself, using
the RFC3041 privacy extensions.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html