Message-ID: <20130506184817.GA2729@open-mesh.com>
Date:	Mon, 6 May 2013 20:48:17 +0200
From:	Antonio Quartulli <antonio@...n-mesh.com>
To:	"David S. Miller" <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Jamal Hadi Salim <jhs@...atatu.com>
Subject: Using skb->mark outside netfilter  (was: [PATCH 0/3] bridge:
 implement restricted forwarding policy)

Hello all,

On Mon, Apr 08, 2013 at 10:41:00 -0700, Antonio Quartulli wrote:
[...]

> The goal we want to achieve by adding this feature consists in selecting a
> subset of the interfaces available on all the hosts participating to the mesh
> network and to prevent packets from being forwarded from one of them to another.
> 
> Looking again at the "very big switch" abstraction this would allow a mesh
> network administrator to define a sort of "not forwarding policy network wide"
> between some of the big switch's port.
> 

I'm resurrecting this thread because after Jamal's suggestion I decided to
finally drop the idea of introducing such a net flag and focus on a different
approach.

The new idea is to use tc to mark packets arriving into the bridge
through a predefined port (chosen by the admin when setting up the tc rule) and
again use tc to drop packets having such mark when they are going out through
another predefined port.

Now to extend this mechanism network-wide (remember that the use case is a Layer2
mesh network set up with batman-adv) I'm going to introduce a mechanism in
batman-adv itself which is supposed to read and write the skb->mark field
so that the value contained when the packet is leaving one end can be restored
later on the other end of the intra-mesh communication (only if it matches a pre
configured one).
This would allow the remote node to perform the same filtering
operation as if the packet was locally generated.

Now my question is (I think David is the one who should probably decide here):
is batman-adv allowed to touch the mark field of the sk_buff structure? Or is it
reserved for netfilter purposes only?

In my opinion this field (which survives whatever path the skb follows) is the
best option for this task as it allows batman-adv to "communicate" with
tc and possibly netfilter itself (if in the future users would like to perform
more complicated operations).


To clarify the idea, here you have an ascii art representing a possible setup
and how the mark will be read and set:


Scenario:
=========
- Two mesh nodes configured the same way.
- Packets arriving via eth0 have to be marked with M.
- Packets marked with M should be dropped before going out through eth1.


           +------+
     ------|bridge|----
    |      +------+    |
    |         |        |
   [M]skb     |       [M]skb
 +------+ +------+ +------+     The skb is generated when arriving on eth0 and
 | bat0 | | eth1 | | eth0 |     is marked with the value M.
 +------+ +------+ +------+     batman-adv (operating in bat0) recognises the
    |                pkt        mark and spread the information in the mesh
 +------+                       (other than forwarding the packet to the mesh).
 |wlan0 |
 +------+
    :bat{pkt}
 ___:_______
/           \
|   MESH    |
\___________/
    :
    :bat{pkt}
 +------+                        batman-adv on the receiving side knows that
 |wlan0 |                        this skb has to be marked and so it writes M
 +------+                        into skb->mark.
    |[]skb		           The skb is now marked and can be dropped as
 +------+ +------+ +------+      instructed.
 | bat0 | | eth1 | | eth0 |
 +------+ +------+ +------+
   [M]skb     |        |
    |         |        |
    |     +------+     |
    ------|bridge|-----
          +------+



Cheers,




-- 
Antonio Quartulli

..each of us alone is worth nothing..
Ernesto "Che" Guevara

Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)

Powered by blists - more mailing lists