X-Original-To: alpine-devel@lists.alpinelinux.org
Delivered-To: alpine-devel@mail.alpinelinux.org
Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115])
	(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.alpinelinux.org (Postfix) with ESMTPS id 36D22DC1667
	for <alpine-devel@lists.alpinelinux.org>; Thu,  5 Jan 2012 07:19:46 +0000 (UTC)
Received: from kunkku.net (kanala.lvi-keskinen.fi [62.142.251.59])
	by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 9D547151590;
	Thu,  5 Jan 2012 09:19:41 +0200 (EET)
Received: from kunkku.net (kunkku.net [127.0.0.1])
	by kunkku.net (8.14.5/8.14.5) with ESMTP id q057JeCv015054;
	Thu, 5 Jan 2012 09:19:40 +0200
Received: from localhost (kaarle@localhost)
	by kunkku.net (8.14.5/8.14.5/Submit) with ESMTP id q057Jdrb015050;
	Thu, 5 Jan 2012 09:19:39 +0200
X-Authentication-Warning: kunkku.net: kaarle owned process doing -bs
Date: Thu, 5 Jan 2012 09:19:39 +0200 (EET)
From: Kaarle Ritvanen <kaarle.ritvanen@datakunkku.fi>
X-X-Sender: kaarle@kunkku.net
To: Harry Lachanas <grharry@freemail.gr>
cc: "alpine-devel@lists.alpinelinux.org" <alpine-devel@lists.alpinelinux.org>
Subject: Re: [alpine-devel] Alpine Wall for firewall management
In-Reply-To: <4F041FB0.10109@freemail.gr>
Message-ID: <alpine.LFD.2.02.1201050906000.14693@kunkku.net>
References: <alpine.LFD.2.02.1112301354560.21584@kunkku.net> <4F041FB0.10109@freemail.gr>
User-Agent: Alpine 2.02 (LFD 1266 2009-07-14)
X-Mailinglist: alpine-devel
Precedence: list
List-Id: Alpine Development <alpine-devel.lists.alpinelinux.org>
List-Unsubscribe: 
	<mailto:alpine-devel+unsubscribe@lists.alpinelinux.org?subject=unsubscribe>
List-Post: <mailto:alpine-devel@lists.alpinelinux.org>
List-Help: <mailto:alpine-devel+help@lists.alpinelinux.org?subject=help>
List-Subscribe: 
	<mailto:alpine-devel+subscribe@lists.alpinelinux.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

On Wed, 4 Jan 2012, Harry Lachanas wrote:

> Very nice effort indeed ...
> However I would like to see some level of abstraction in the ZONE specification.
> That is,
> 
> Instead of a 1 to 1 relation between zone and interface+subnet
> 
> I would like to attach an ipset there as a part of a zone.
> 
> In other words
> 
> Zone = ( iface ) U ( subnet(s) ) U ( ipset )

I'm not sure what your use case is, but I could interpret this in two
alternative ways:

1. User configures a complex zone consisting of serveral host and/or
subnet addresses. Alpine Wall optimizes the zone lookup by constructing an
ipset based on the definition, which is then used in the actual rules.

2. User defines the zone with a reference to an existing ipset, which is
managed manually or by some other tool.

I think both are valid use cases. The second one is particularly useful 
e.g. in connection with captive portal authentication.

Now that we got into set theory, I was actually thinking an intersection 
between the interface and subnet definitions rather than union. If a 
packet with source address <a> arrives on interface <i>, it is considered 
to originate from zone Z = (I, S) (where I is the set of interfaces and S 
is the set of subnets) if and only if I includes <i>, and <a> belongs to 
any subnet of S. In zone definitions, I would default to the set of all 
interfaces and S to {0.0.0.0/0, ::}. The destination zone would be defined 
in a similar way based on the packet's destination address and interface.

> This should also consider the aspect if incoming and outgoing connections, so
> expanding this would impose
> ZONE = ( iface ) U ( Subnet(s) ) U ( ipset/Incoming ) U ( ipset/outgoing )

Why would you need separate ipsets for incoming and outgoing packets? 
Couldn't you just define two zones?

BR,
Kaarle


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---