[Oisf-devel] RFC: vlan_id in flow tracking

[Victor Julien]

On 04/08/2013 02:58 PM, Chris Wakelin wrote:
> On 08/04/13 13:45, Victor Julien wrote:
>> 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
>>
> 
> Yes, from a port-mirror of all the traffic
> 
>> 2. connection on inside only: fully tagged?
>>
> 
> Yes, I think so, but at the moment we're only monitoring the borders
> (three of them!)

I was wondering, are you monitoring all this on a single interface, or
do you have multiple interfaces, one for each above case?

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