Re: ebt_inat

On Mon, 15 Sep 2003, Bart De Schuymer wrote:

> Hi,
>
> Some comments on the code/implementation:
>
> - Change i{d,s}nat-default-target to isnat-target, since all other extensions
> do it the same way.

I have named this i{d,s}nat-default-target, because it works somewhat
different than *-target for other targets. This i{d,s}nat-default-target
is applied not to all packets, but only to these packets, which are not
mentioned in the i{d,s}nat-list.

If you like, I'll rename as isnat-target, but IMHO it will be somewhat
misleading.

> - The idnat target should not be allowed in the brouting table.

OK

> - It is unclear from the help messages what this target actually does, try
> writing a general description of the target before stating the options.

OK

> - Use /* */ for comments, never //. Please do this in your other code too, I
> forgot to mention that. The use of // is C++.

OK

> - The '_' action, meaning DROP the frame, seems kind of out of place in a
> "nat" target. I vote for removing this.

In my firewall, I heavily use DROP in nat. And leaving '_' action allows
to combine indexed NAT with mac-security in one rule, thus saving the CPU.

> - I think the default for tuple->target should be ACCEPT, make '+' denote
> CONTINUE.

OK

> In a previous mail you said you were going to do the same for arpreply and
> mark. I don't think this is worth the trouble though, unless anyone knows
> situations in which a lot of rules for marking/arpreplying, specifically by
> filtering on IP addresses, are needed.

It would be good if a switch could generate reply for ARP requests about
many IP's. It would reduce the broadcast traffic. It can also fool the
intruders by simulating many distinct hosts on one box, etc.

Of course, in iarpreply, destination IP address would be used as index,
not source. There is no point in replying differently to different
requesters asking of the same host, but there is feasible to let make
different replies to asks of different hosts.

And imark would help to classify a packet. Different IP addresses could
therefore be treated differently in further processing.

If nobody needs such features, OK - I will not create them, because I
don't need them much, too.

> Ofcourse, I'm open for discussion (we should CC ebtables-devel). We must
> beware of creeping featurism. I'm not even sure if there are situations
> in which lots of IP addresses need to be assigned to different MAC
> addresses.

I had such a situation, and this led me to create this extension.

I administrate the network in a student hostel, and this network is a part
of greater academic LAN. The gateway, which holds MAC/IP pairs lies far
away and I don't administrate that.

During vacation, I have problems with contact with administrator of the
gateway (he is absent and his substitution is poorly available) and
therefore problems with updating the pairs. And there was a great storm,
which spoiled some users' network cards. People have replaced them
quickly, but these could not work if I didn't insert some dnat/snat rules
to the bridge. These rules, however, weighed this old K6 down (running in
100 Mbps FD), consuming the whole CPU time and dropping some packets. So I
wrote inat to improve the performance.

Yes, this is an unusual situation. But if it happened, and I wrote inat, I
would like to share this.

-----------------

Your comments to inat and among will be applied tomorrow and committed.

BTW I have another idea. What about an option --arpreply-mac AUTO, which
would do the following:

- if we have this IP in the ARP cache, we answer and drop.

- if not, we pass this packet and wait for the reply.

To make this work, however, we would need also an additional target, name
it arpcache, which would remember all trespassing ARP-reply packets (maybe
not only ARP-reply packets) to the local ARP cache.

That all would allow to make a very large LANs without risk of being
flooded by broadcast ARP request packets.

If somebody is interested, I can extend arpreply in this way.

-- 
Grzesław


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf