[Oisf-devel] RFC: vlan_id in flow tracking

Eric Leblond eric at regit.org
Mon Apr 8 11:44:40 UTC 2013


On Thu, 2013-04-04 at 13:10 +0200, Victor Julien wrote:
> (RFC: request for comments :))
> Suricata currently parses VLAN headers but doesn't really do anything
> with them. This is obviously wrong in some cases, like in flow tracking.
> There can be several vlan's on a network, where in each we see the same
> 5-tuple. These shouldn't be mixed, but right now they can be.
> This patch tries to deal with it:
> https://github.com/inliniac/suricata/commit/d755fdfdc4576057712ccdb70f1e3a17bfad901c
> There are a few open issues:
> - what to do in case of multiple layers of VLAN? We should probably be
> taking the tunnel approach, where we create a fake packet

If people are separating client networks by using first VLAN and if
second VLAN is the one used in client network, the tunneling approach
will not work.
For now, I would say the best approach may be to use the outer VLAN id
as tag in flow. But It might only be my way of seeing thing, so a choice
could be done via a configuration variable.

> - there are reports of broken switches (Chris) that only append vlan
> tags to one direction of the flows. To handle this correctly the vlan id
> tracking would have to be optional

We have to force people to upgrade their switches. It is good for the
economy! Seriously, VLAN tracking has to be optional even to address the
issue with multiple layers of VLAN.

Eric Leblond <eric at regit.org>
Blog: https://home.regit.org/

More information about the Oisf-devel mailing list