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: <4ED5793E.1090003@ans.pl>
Date:	Wed, 30 Nov 2011 01:30:54 +0100
From:	Krzysztof Olędzki <ole@....pl>
To:	Ben Hutchings <bhutchings@...arflare.com>
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 2011-11-30 01:05, Ben Hutchings wrote:
> 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?

Oh, I understand your point. But I'm looking at it from the other side 
as I'm here to protect my users. ;)


Best regards,

			Krzysztof Olędzki

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