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 for Android: free password hash cracker in your pocket

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

Date:	Tue, 29 Nov 2011 13:23:52 +0100 (CET)
From:	Jan Engelhardt <jengelh@...ozas.de>
To:	Ulrich Weber <ulrich.weber@...hos.com>
cc:	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 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.

Everybody should come out of their worshipping NAT for anonymity
now - at best, that is an Emperor's Clothes' kind of anonymity.

> Think of Tor: If your server/client operates with private IP addresses,
> your public IP address is still masked after a security breach.

If one's tor peer was busted, they would have the address.
--
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