[Oisf-devel] RFC: vlan_id in flow tracking

[Eric Leblond]

Hi,

On Mon, 2013-04-08 at 14:35 +0200, Victor Julien wrote:
> On 04/08/2013 01:44 PM, Eric Leblond wrote:
> > Hi,
> > 
> > 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.
> 
> How do you mean? Each vlan id should be a unique network, right?

Yes but I was thinking to this setup:

| Client Vlan | Network VLAN | Datagram |

If we do a tunnel and remove Client Vlan, the result is a multiclient
packet:

| Network VLAN | Datagram |

where Network (private IP for example) may be shared among client. And
if we have no luck, then we can cross beams and have two clients with
same network under the same VLAN. 

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