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  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]
Date:	Sun, 24 Jun 2007 17:51:33 -0400
From:	Kyle Moffett <>
To:	Jan Engelhardt <>
Cc:, LKML Kernel <>,
	Andrew Morton <>,
Subject: Re: Scaling Max IP address limitation

On Jun 24, 2007, at 15:58:54, Jan Engelhardt wrote:
> On Jun 24 2007 15:08, Kyle Moffett wrote:
>> Do you really need that many IP addresses?  When somebody finally  
>> gets around to implementing REDIRECT support for ip6tables then  
>> you could just redirect them all to the same port on the local  
>> system.
> The way I see it, it's: "if someone gets around to implement *IPv6  
> NAT*" (which, if its designers were asked, is contrary to the idea  
> of ipv6).

I totally agree.  On the other hand, you need REDIRECT for things  
like transparent proxies which by definition aren't visible as  
anything other than a router or bridge.

>> Having routing table operations, IPsec transformations, etc just  
>> be another step in the firewall rules would also be useful.  It  
>> would be handy to be able to "-j ROUTE", then "-j IPSEC", then "-j  
>> ROUTE" again, to re-route the now-encapsulated IPsec packets to  
>> their proper destination.
> Absolutely...
>> That would also eliminate the sort-of-hacky problems with  
>> destination network interface in the bridging code:
> Where's the hack? iptables operates on what it sees, and it sees  
> br0.  The physdev match is justified IMO.

The problem is this:
I want to be able to filter bridged network traffic *both* based on  
the IP layer *and* the physical device it's going to be routed out.   
Due to fundamental problems with a statically-ordered architecture,  
it's impossible to get both, see commit  
68df071a201f06b08cdc07111c6d4af918e64edd (found here: http:// 
026388.html).  Basically if you want such cross-layer hooks, right  
now your *ONLY* choice is to use marks with 2 drawbacks:  (1)  There  
are a very small number of marks which must be carefully allocated by  
your firewall-setup script  (2)  Marks are inherently extremely  
fragile for passing data between layers.

>> "-j BRIDGE" might be another step in the process, and conceivably  
>> you could have independent bridge MAC tables too.
> Whether a packet goes out a bridge (was that the intention of -j  
> BRIDGE?) is determined by the routing table, which, in most cases,  
> is just a matter of destination address.

No, the intent of "-j BRIDGE" would be _after_ "-j ROUTE" and some  
kind of "-j ARP", to actually compute which physical port a given  
packet should go.

>> That would also appear to get rid of the need for all tables other  
>> than
>> "filter" and all predefined chains other than "INPUT" and  
>> "OUTPUT".  Default
>> rules would be these:
>> nettables -A INPUT -j CONNTRACK
>> nettables -A INPUT -j LOCALMATCH
>> nettables -A INPUT --for-this-host -j ACCEPT
>> nettables -A INPUT -j OUTPUT
> I'd prefer if Linux outputted its packets by default :)

Well the problem is this:  Do you want the packet accepted locally or  
forwarded.  If forwarded, how do you want it routed, and which  
physical port do you want it to go out?  Without a statically-coded  
ordering for all those things there is no way to say what the  
"default" is.  You would need some way to switch between iptables/ 
ip6tables (for compatibility) and pkttables/nettables (for advanced  

> But this idea may have its benefit: by not restricting rules to  
> certain positions like currently, throughput could be achieved.  
> "Evil packets" f.e. could be dropped really early. (Well, you could  
> also drop them early _today_, but a DROP in the mangle table will  
> everyone make their eyes roll

It does give you a million more ways to shoot yourself in the foot.   
Some things would have constraints like "output device must be  
set" (BRIDGE/ARP, for example).  If you accidentally stuck non- 
constrained things in the wrong order you could get totally-non-IP- 
compliant behavior.  On the other hand, it does give you many choices  
about IPsec before or after ROUTING (or after one routing step and  
before another), etc.

Kyle Moffett

To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists