[Oisf-devel] RFC: vlan_id in flow tracking

Victor Julien victor at inliniac.net
Mon Apr 8 12:45:25 UTC 2013


On 04/08/2013 02:02 PM, Chris Wakelin wrote:
> On 08/04/13 12:44, 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.
>> 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.
>>
> 
> Alas Extreme 10GB border switches aren't cheap, and tagging only one
> direction in a mirrored port is "by design" apparently. Presumably it's
> to mark the direction and if they tagged both directions but with a
> different VLAN tag, it would be just as awkward for us. We wouldn't get
> our border switches upgraded just to make it easier for IDS either. I
> might just about be able to persuade the network manager to go for a
> fibre tap instead though.

Just to make sure I understand how things work in your case.

1. connection passing through border: one direction tagged, other not

2. connection on inside only: fully tagged?

-- 
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------




More information about the Oisf-devel mailing list